Re: Can I create a package with friendly modules
On Sunday, 12 June 2022 at 05:05:46 UTC, forkit wrote:
Is it possible to create a package.d, consisting of (for
example), two modules, where each module can access private
declarations within each other.
In essence, declaring 'a module level friendship', or a kind of
'extended module' if you want.
I might still want to add another module to the package, that
is NOT part of that friendship between those other two modules,
but is otherwise related to the solution.
- packagename
-- package.d
-- futuremodule.d
--- subpackagename
friend1.d
friend2.d
```
// friend1.d
module packagename.subpackagename.friend1;
package void doSomethingFriendly();
///
// friend2.d
module packagename.subpackagename.friend2;
import packagename.subpackagename.friend1;
void doSomething() { doSomethingFriendly(); }
///
// package.d
module packagename;
public import
packagename.subpackagename.friend1,
packagename.subpackagename.friend2,
packagename.futuremodule;
```
Re: Can I create a package with friendly modules
On Sunday, 12 June 2022 at 05:05:46 UTC, forkit wrote: e.g. If I could something like this: // foo_1.d module foo_1 private int a; // a is private to module foo_1 // foo_2.d module foo_2 private int b; // b is private to module foo_2 // foo.d module foo[dependencies:foo_1, foo_2]; import std; writeln a; // can call foo_1.a directly even those its private to that module writeln b; // can call foo_2.b directly even those its private to that module
Can I create a package with friendly modules
Is it possible to create a package.d, consisting of (for example), two modules, where each module can access private declarations within each other. In essence, declaring 'a module level friendship', or a kind of 'extended module' if you want. I might still want to add another module to the package, that is NOT part of that friendship between those other two modules, but is otherwise related to the solution.
Re: UI Library
On Saturday, 11 June 2022 at 21:44:17 UTC, harakim wrote: I tried the solution I suggested and it did not work because the child would occlude the parent (which is in the comments now that I see it.) yeah minigui's model is to tile the widgets; they aren't supposed to overlap (except their parent, but then they cover the parent) I decided to stick to simpledisplay strictly and forgo using the minigui library for the time being, and that is working well. Yeah, nested widgets are something i sometimes use btu more often then not, i'll make the whole display for a thing - say a graph - just be a single widget and paint it in there. A simpledisplay window's paint code can generally be pasted into a single minigui widget's paint code without much modification (the minigui WidgetPainter actually is a subclass of simpledisplay's ScreenPainter)
Re: UI Library
On Saturday, 11 June 2022 at 01:20:17 UTC, harakim wrote: The issue I'm having is that I don't understand how to assign bounds in the nested widget. I'm sure there's a very clean solution. I basically want a paintContent method but with the bounds dynamically assigned by the parent. Well the bounds given to paintContent just define your content area boundaries, relative to the nested widget. The content area is inside its own border. The actual position is assigned by the parent (the virtual function there is recomputeChildLayout, you can override that to arrange instead of letting it automatically fill the space). I don't really know what exactly you have in mind for the bounds, but anything outside your widget area is going to be clipped anyway, so I think you really want to change that child layout computation.
Re: UI Library
On Saturday, 11 June 2022 at 01:20:17 UTC, harakim wrote: On Friday, 20 May 2022 at 12:07:46 UTC, Adam D Ruppe wrote: On Friday, 20 May 2022 at 03:47:14 UTC, harakim wrote: Thank you. I will definitely give that a try. But just ask me if something comes up since I can push fixes to master p quickly. If there is a more elegant solution, then I will use it. Otherwise, this solution will work fine with some comments. I tried the solution I suggested and it did not work because the child would occlude the parent (which is in the comments now that I see it.) I decided to stick to simpledisplay strictly and forgo using the minigui library for the time being, and that is working well.
Re: a struct as an multidimensional array index
On 6/11/22 13:36, z wrote: > i meant with the syntax in (1), the spec's documentation appears to say > they are equivalent in result with `new *type*[X][Y]` form. > > (1) https://dlang.org/spec/expression#new_multidimensional (3. multiple > argument form) Thank you. I see now: The values in parentheses are the lengths from the outermost to the innermost: new int[][][](5, 20, 30) // The equivalent of int[30][20][5] Although, I can see how it had to be that way so that when one used less number of lengths, the syntax always works from outer to inner in that new expression: new int[][][](5) // The equivalent of int[][][5] Ali
Re: a struct as an multidimensional array index
On Saturday, 11 June 2022 at 15:01:05 UTC, Ali Çehreli wrote: On 6/11/22 00:09, z wrote: > I rechecked and it should be `X Y Z` for static array, but `Z Y X` for > indexing/dynamic array creating with `new` How so? i meant with the syntax in (1), the spec's documentation appears to say they are equivalent in result with `new *type*[X][Y]` form. (1) https://dlang.org/spec/expression#new_multidimensional (3. multiple argument form)
Re: sha256 to bigint
On Saturday, 11 June 2022 at 13:09:44 UTC, vc wrote:
Hello, is there any way to represnts a sha256 hash like
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 in BigInt ?
I've try so far auto t =
BigInt("2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824") and it gives me invalid digit
Just so you know, you can construct a `BigInt` directly from the
raw bytes of a sha256 hash, without converting to a string first:
```d
import std.digest.sha, std.bigint;
ubyte[32] hash = sha256Of(whatever);
auto t = BigInt(false, hash[]); // sign + magnitude
```
Docs: https://phobos.dpldocs.info/std.bigint.BigInt.this.3.html
Re: a struct as an multidimensional array index
On 6/11/22 00:09, z wrote:
> I rechecked and it should be `X Y Z` for static array, but `Z Y X` for
> indexing/dynamic array creating with `new`
How so? I wrote the following program:
import std.stdio;
void main() {
enum X = 2;
enum Y = 3;
enum Z = 4;
int[X][Y][Z] s;
int[X][Y][] d = new int[X][Y][Z];
pragma(msg, typeof(s));
pragma(msg, typeof(d));
}
It outputs the following for the static and the dynamic arrays:
int[2][3][4]
int[2][3][]
Consistent elements, except the static array has a compile-time known
length.
Ali
Re: a struct as an multidimensional array index
On 6/11/22 04:16, Salih Dincer wrote:
> I think D is very consistent with our feelings. That is, the order in
> memory is in the form of rows x columns.
Yet, there are no rows or columns because neither D nor C (nor C++) have
multip-dimensional arrays. They all have arrays where elements are layed
out in memory consecutively.
The type of the elements and what they represent is entilery up to the
programmer.
> But yes, in reverse(column x
> row) when you set it up statically.
If you mean we can set up the memory in any way we want, I agree but
again, since there are no mult-dimensional arrays, there cannot be the
reverse of the order.
> This sample code working on pointers
> can be a proof:
If it's prooving that elemets are side-by-side, then it's by spec.
Here is an example where I have array where each element is a column:
import std.stdio;
import std.range;
import std.algorithm;
void main() {
// I decide that this array represents
// Three rows of two columns.
int[][] arr;
arr.length = 2;
foreach (ref column; arr) {
column.length = 3;
}
setFirstColumn(arr, 1);
printArray(arr);
}
void setFirstColumn(int[][] arr, int value) {
// The first element is my first column.
arr[0][] = value;
}
void printArray(int[][] arr) {
// Because stdout takes line-by-line,
// we print a transposition.
arr.transposed.writefln!"%-(%-(%s %)\n%)";
}
You may think that the final transposition is a trick. No, it was needed
only because stdout takes line-by-line. If I used a library like
ncurses, I could have printed my array exactly the way I used it.
The point is, there are no multi-dimensional arrays. Programmers use
arrays as they need and sometimes the elements are arrays.
Ali
Re: sha256 to bigint
On Saturday, 11 June 2022 at 13:09:44 UTC, vc wrote:
Hello, is there any way to represnts a sha256 hash like
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 in BigInt ?
I've try so far auto t =
BigInt("2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824") and it gives me invalid digit
Ok i think is solved using "0x" infront, auto t = BigInt("0x"
~"2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824")
Re: Why allow initializers of non-static members that allocate?
On Saturday, 11 June 2022 at 10:52:58 UTC, Mike Parker wrote: I agree with your initial assessment that it should be an error. It really only makes sense to allow the dynamic allocation if the fields are immutable and, in the case of arrays, the initializer is a literal.
sha256 to bigint
Hello, is there any way to represnts a sha256 hash like
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
in BigInt ?
I've try so far auto t =
BigInt("2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824") and it gives me invalid digit
Re: Error: cannot use non-constant CTFE pointer in an initializer `cast(immutable(char)*)TEST`
On Saturday, 11 June 2022 at 11:51:43 UTC, Tejas wrote:
On Saturday, 11 June 2022 at 10:07:46 UTC, test123 wrote:
how to work this around.
```d
__gshared const TEST = import(`onlineapp.d`);
extern(C) void main(){
__gshared bin_ptr = TEST.ptr;
}
```
```sh
dmd2 -betterC -J. onlineapp.d
onlineapp.d(3): Error: cannot use non-constant CTFE pointer in
an initializer `cast(immutable(char)*)TEST`
```
Maybe try putting `__gshared bin_ptr = TEST.ptr;` inside a
`shared static this(){}`?
I mean, write it like:
```d
__gshared bin_ptr;
shared static this()
{
bin_ptr = TEST.ptr;
}
__gshared const TEST = import(`onlineapp.d`);
extern(C) void main()
{
}
```
But `bin_ptr` becomes a global in this case :(
Oh wait, `-betterC` is being used ;(
hmm...
Use
[pragma(crt_constructor)](https://dlang.org/spec/pragma.html#crtctor) instead
```d
__gshared immutable(char)* bin_ptr;
pragma(crt_constructor)
void init_ptr()
{
bin_ptr = TEST.ptr;
}
__gshared TEST = import("this.d");
extern(C) void main()
{
}
```
```sh
(base) [tejasgarhewal@fedora D]$ ldc2 -J. -betterC this.d
(base) [tejasgarhewal@fedora D]$ ./this
```
Re: Error: cannot use non-constant CTFE pointer in an initializer `cast(immutable(char)*)TEST`
On Saturday, 11 June 2022 at 10:07:46 UTC, test123 wrote:
how to work this around.
```d
__gshared const TEST = import(`onlineapp.d`);
extern(C) void main(){
__gshared bin_ptr = TEST.ptr;
}
```
```sh
dmd2 -betterC -J. onlineapp.d
onlineapp.d(3): Error: cannot use non-constant CTFE pointer in
an initializer `cast(immutable(char)*)TEST`
```
Maybe try putting `__gshared bin_ptr = TEST.ptr;` inside a
`shared static this(){}`?
I mean, write it like:
```d
__gshared bin_ptr;
shared static this()
{
bin_ptr = TEST.ptr;
}
__gshared const TEST = import(`onlineapp.d`);
extern(C) void main()
{
}
```
But `bin_ptr` becomes a global in this case :(
Re: a struct as an multidimensional array index
On Friday, 10 June 2022 at 17:26:48 UTC, Ali Çehreli wrote:
I've written about this multiple times in the past but D's way
is consistent for me. That must be because I always found C's
syntax to be very illogical on this. [...]
I think so too...
I think D is very consistent with our feelings. That is, the
order in memory is in the form of rows x columns. But yes, in
reverse(column x row) when you set it up statically. This sample
code working on pointers can be a proof:
```d
void main()
{
enum
{
Row = 2,
Column = 3
}
size_t cal = Row * Column * int.sizeof;
auto alloc = new ubyte[cal];
size_t m = Column * int.sizeof;
int[][] aSlice;
foreach (i; 0 .. Row)
{
size_t n = i * m;
aSlice ~= cast(int[])alloc[n .. n + m];
}
auto row = 2;
auto column = 3;
aSlice[row-1][column-1] = 1; // last element
assert(
*( [0][0] // first element pointer
+ (row * column - 1)
)
); // no error...
//If you want to see it with your eyes:
import std.stdio;
aSlice.writefln!"%-(%-(%s %)\n%)";
}
```
SDB@79
Re: Why allow initializers of non-static members that allocate?
On Saturday, 11 June 2022 at 10:37:30 UTC, Bastiaan Veelo wrote: So that’s why I used “why” in the title of this thread, which I haven’t seen an answer to yet. What is the practical case where that warning would be annoying? When would you actually want this behaviour? After actually stopping to think about it (my earlier responses were reflexive), I agree with your initial assessment that it should be an error. It really only makes sense to allow the dynamic allocation if the fields are immutable and, in the case of arrays, the initializer is a literal.
Re: Why allow initializers of non-static members that allocate?
On Saturday, 11 June 2022 at 01:52:58 UTC, Mike Parker wrote: People getting bit by `new` in field initialization often enough that I think a warning would be helpful. The problem is so much bigger because it is not just a case of being aware not to use `new` in member initialisers. As you see in my second example in https://forum.dlang.org/post/ogvubzgprghefclgl...@forum.dlang.org there is no `new` anywhere. In fact you could say an effort has been made to do the right thing in `struct A` where the allocation has been moved to the constructor (a strategy that is not always available because structs don’t have default constructors) yet we fell into the same trap. My point is that this problem can be buried deep down under multiple layers and you can’t really ever be sure that there isn’t a problem in your massive code base. But any such warnings need to be enabled by default to be useful, and must have an off switch for people who don't need them. So the question in each case would be, where's the line between helpful and annoying? So that’s why I used “why” in the title of this thread, which I haven’t seen an answer to yet. What is the practical case where that warning would be annoying? When would you actually want this behaviour? — Bastiaan.
Error: cannot use non-constant CTFE pointer in an initializer `cast(immutable(char)*)TEST`
how to work this around.
```d
__gshared const TEST = import(`onlineapp.d`);
extern(C) void main(){
__gshared bin_ptr = TEST.ptr;
}
```
```sh
dmd2 -betterC -J. onlineapp.d
onlineapp.d(3): Error: cannot use non-constant CTFE pointer in an
initializer `cast(immutable(char)*)TEST`
```
Re: a struct as an multidimensional array index
On Saturday, 11 June 2022 at 03:56:32 UTC, Chris Katko wrote: On Friday, 10 June 2022 at 17:26:48 UTC, Ali Çehreli wrote: On 6/10/22 08:13, z wrote: > arrays of arrays has different order for declaration and addressing, > and declaring array of arrays has different order depending on how you > declare it and wether it's static or dynamic array, *oof*) > > To give you an idea of the situation : > ```D > int[3][1] a;//one array of 3 int > writeln(a[0][2]);//first "column", third "row" > ``` I've written about this multiple times in the past but D's way is consistent for me. That must be because I always found C's syntax to be very illogical on this. To me, C's problem starts with putting the variable name in the middle: // C code: int a[1][3]; // Why? So, first, D moves the variable to its consistent place: after the type: int i; int[N] arr; Both of those are in the form of "type and then name". Good... And then, here is the consistency with arrays: "type and then square brackets". int[] dynamicArray; int[N] staticArray; So, here is where you and I differ: int[3][1] arr; // Ali likes int[1][3] arr; // z wants I like it because it is consistently "type and then square brackets". (It so happens that the type of each element is int[N] in this case.) If it were the other way, than array syntax would be inconsistent with itself. :) Or, we would have to accept that it is inside-out like in C. But of course I understand how it is seen as consistent from C's point of view. :) And this is consistent with static vs dynamic as well because again it's "type and then square brackets": int[1][] a; // A dynamic array of int[1] int[][3] b; // A static array of 3 int[]s Ali This is an interesting discussion. I had noticed multi-dim arrays seemed backwards but I assumed I was doing something wrong and had other thing to worry about. I had no idea it was DIFFERENT for static vs dynamic arrays? That's horrifying! Also you reminded me of a possible D bug that I ran into. I had classes that had circular dependencies. One had to know about the other, and vice-versa. And I had derived classes. But somehow, they would explode. I would send one reference to the others constructor to 'link' them together, but the reference would be NULL. But if I accessed the exact same variable through a global reference, it worked fine. I tried ripping the affected code into a new file but the bug wasn't replicated. Even if I matched the compiler/linker options. It was super frustrating. I rechecked and it should be `X Y Z` for static array, but `Z Y X` for indexing/dynamic array creating with `new` (e.g. `float[][][] arr = new float[][][](third_dimension,second_dimension,first_dimension;`) The dillema is that alone, the orders are sound byproducts of the language rules, it's when they are put in relation to each other that it can become weird. The bug could also be one of those implementation-specific bugs that are seemingly impossible to reproduce minimally because they require unknown very specific conditions to occur. Self and inter referencing appears unstable whenever it is not in the module/global scope.
Re: Why allow initializers of non-static members that allocate?
On Saturday, 11 June 2022 at 02:22:28 UTC, matheus wrote: Well would this be annoying? Yes, mainly if I already know this, but if not, then it would be like a nice to know warning for newbies like myself. By the way this would be only in the cases that a static array field being initialized with dynamic allocation like in the case of struct declaration, not on every place. I agree... I'd be wrong too if I didn't know that while reading the code. I think there should be a warning when compiling. Really, is it so hard to put up a warning? SDB@79
