Re: GtkD CRUD Application

2020-10-17 Thread Ferhat Kurtulmuş via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:53:35 UTC, Alaindevos wrote:

I've written the beginning but dont know how to end.
What is the way to add functionality for the add,edit,delete 
button ?

//==


I put an example[1] here. The fields are not editable. You will 
have to implement it. I think you will get the idea to do that.


My example uses ListBox with a fake header as a bonus. You can 
use TreeView, but it is a complex widget.


[1] 
https://gist.github.com/aferust/47cb782b55cdab1f7775b7755bc50982


Re: How to rebind the default tkd GUI keybinds?

2020-10-17 Thread starcanopy via Digitalmars-d-learn

On Saturday, 17 October 2020 at 09:33:04 UTC, tastyminerals wrote:

On Sunday, 11 October 2020 at 18:51:17 UTC, tastyminerals wrote:
Tk default keys are somewhat different from what we used to 
use for selecting, copying and pasting the text. So, any Tk 
based GUI app starts with writing the rebinding function for 
"ctrl+a", "ctrl+c", "ctrl+x" and "ctrl+v" keys, at least. I 
did it when writing TkInter based apps in Python. Today I am 
trying out tkd and want to do the same. However, it doesn't 
work :(


For example:

private void selectText(CommandArgs args) {
this._clientId.selectText;
}

this._loginFrame = new Frame(2, ReliefStyle.groove);
this._clientId = new Entry(loginFrame).grid(1, 0);
this._clientId.bind("", );

It works if I change "" to "" for 
example.

But how do I overwrite the actual "" key in tkd?


So, this is even tricky in Python TkInter but possible.
In tkd this is not possible unfortunately.


You could try directly calling 
[bindtags](https://www.tcl.tk/man/tcl8.4/TkCmd/bindtags.htm) with 
_tk.eval. Modifying and extending tkd is easy from my experience 
where I had added support for additional image formats. (After 
blundering about on how to get tcl/tk to work, lol.)


Re: vibe.d / experience / feedback

2020-10-17 Thread Andre Pany via Digitalmars-d-learn

On Saturday, 17 October 2020 at 16:35:29 UTC, shamsmehra90 wrote:
I could not even find demo code doing a redirect which is the 
most basic stuff. https://mcdvoicesurvey.onl 
https://mybk-experience.onl


There are 6 examples doing a redirect:
https://github.com/vibe-d/vibe.d/search?q=redirect=


Also doing a google search for:
vibe.d redirect
Will show you the correct api as first hit.

Kind regards
Andre


IRe: GtkD CRUD Application

2020-10-17 Thread aberba via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:53:35 UTC, Alaindevos wrote:

I've written the beginning but dont know how to end.
What is the way to add functionality for the add,edit,delete 
button ?

//==
import gtk.Button;
import gtk.Box;
import gtk.Label;
import gtk.Entry;
import gtk.Grid;
import gtk.Main;
import gtk.MainWindow;
import gtk.Widget;
import gdk.Event: Event;
import std.array: assocArray;
import std.conv: to;
import std.format : format;
import std.range: iota, retro, drop, zip;
import std.stdio: writeln;

[...]




I haven't used GTK in d myself in a long time. But gtkdcoding.com 
is s great place to see some code. You might want to start from 
the first post


Re: vibe.d / experience / feedback

2020-10-17 Thread shamsmehra90 via Digitalmars-d-learn
I could not even find demo code doing a redirect which is the 
most basic stuff. https://mcdvoicesurvey.onl 
https://mybk-experience.onl


Re: Forward referencing functions in D

2020-10-17 Thread Ali Çehreli via Digitalmars-d-learn

On 10/17/20 8:28 AM, NonNull wrote:

On Friday, 16 October 2020 at 21:28:18 UTC, Steven Schveighoffer wrote:

Inner functions have benefits:

1. They are only accessible inside the function. Which means you only 
have to worry about correctness while INSIDE that function.

2. inner functions have access to the outer function's stack frame.

Often, I use inner functions to factor out a common piece of code that 
I don't want to have to write multiple times in the same function.


-Steve


How can you write two inner functions that call each other? (Recursively)


I thought of the following method just now. Yes, there are lambdas but 
who cares? :) (Besides, 'a' can be defined as a proper function below.)


import std.range;

void foo(string s) {
  // b is not initialized yet
  void delegate() b;

  // a is initialized
  auto a = {
while (!s.empty) {
  s.popFront();
  b();
}
  };

  // Set b to a lambda
  b = {
while (!s.empty) {
  s.popBack();
  a();
}
  };

  a();
}

void main() {
  foo("hello");
}

Ali


Re: Forward referencing functions in D

2020-10-17 Thread NonNull via Digitalmars-d-learn
On Friday, 16 October 2020 at 21:28:18 UTC, Steven Schveighoffer 
wrote:

Inner functions have benefits:

1. They are only accessible inside the function. Which means 
you only have to worry about correctness while INSIDE that 
function.
2. inner functions have access to the outer function's stack 
frame.


Often, I use inner functions to factor out a common piece of 
code that I don't want to have to write multiple times in the 
same function.


-Steve


How can you write two inner functions that call each other? 
(Recursively)


Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread NonNull via Digitalmars-d-learn

On Saturday, 17 October 2020 at 15:03:29 UTC, Dennis wrote:
If you want to exactly match the original C code's semantics, I 
suggest translating (unsigned) long with c_long or c_ulong. You 
can import them here:

```
import core.stdc.config: c_long, c_ulong;
```

Then you could add this:
```
static assert(c_long.sizeof == size_t.sizeof);
```

This will fail on Windows 64 bit, where C longs are 32-bit and 
pointers 64-bit.


That is useful information in general, I did not know about 
core.stdc.config and it is useful in future projects!


But for my project the C works at 64 bits except on Windows for 
the reason you gave. So by translating long in C to long in D it 
loses 32 bits but gains 64 bits on Windows. This is what I want.


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn
On Saturday, 17 October 2020 at 13:42:46 UTC, Steven 
Schveighoffer wrote:
I think it *should* be possible to do this, if it's not 
already, just with pragmas. (i.e. pack T but not S).


Agree, a pragma, say `pragma(pack)`, to control this would be 
great to avoid the unsafe union hack.


Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread NonNull via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:56:35 UTC, Adam D. Ruppe wrote:

On Saturday, 17 October 2020 at 14:50:47 UTC, NonNull wrote:
I have inherited an open source C project that assumes that 
the size of a long and the size of a pointer are the same


static assert(long.sizeof == void*.sizeof);


That's a nice clean answer!


Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread NonNull via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:56:33 UTC, Basile B. wrote:

On Saturday, 17 October 2020 at 14:50:47 UTC, NonNull wrote:
I have inherited an open source C project that assumes that 
the size of a long and the size of a pointer are the same, and 
I have translated it into very similar D just like 
https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/


D has the size of long fixed at 64 bits, so a pointer now has 
to be 64 bits.


No it's wrong. A pointer always has the size of a general 
purpose register.


You misunderstand. The original C only works if the size of a 
pointer is the same as the size of a long. So when translated 
into D in a simple way where the size of a long is always 64 bits 
the D will only work if the size of a pointer is 64 bits.


Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread Dennis via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:50:47 UTC, NonNull wrote:
I have inherited an open source C project that assumes that the 
size of a long and the size of a pointer are the same, and I 
have translated it into very similar D just like 
https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/


D has the size of long fixed at 64 bits, so a pointer now has 
to be 64 bits.


If you want to exactly match the original C code's semantics, I 
suggest translating (unsigned) long with c_long or c_ulong. You 
can import them here:

```
import core.stdc.config: c_long, c_ulong;
```

Then you could add this:
```
static assert(c_long.sizeof == size_t.sizeof);
```

This will fail on Windows 64 bit, where C longs are 32-bit and 
pointers 64-bit.


Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread Adam D. Ruppe via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:50:47 UTC, NonNull wrote:
I have inherited an open source C project that assumes that the 
size of a long and the size of a pointer are the same


static assert(long.sizeof == void*.sizeof);


Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread Basile B. via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:50:47 UTC, NonNull wrote:
I have inherited an open source C project that assumes that the 
size of a long and the size of a pointer are the same, and I 
have translated it into very similar D just like 
https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/


D has the size of long fixed at 64 bits, so a pointer now has 
to be 64 bits.


No it's wrong. A pointer always has the size of a general purpose 
register.


So I want to put something into the source to ensure an attempt 
to make a 32 bit build fails. What is the best way to do this?


anyway you have several options:

---
version(X86)
static assert (false, "not for i386");
---

or

---
static assert (size_t.sizeof != 4, "blablalala");
---


Best way to confine project to 64 bit builds only?

2020-10-17 Thread NonNull via Digitalmars-d-learn
I have inherited an open source C project that assumes that the 
size of a long and the size of a pointer are the same, and I have 
translated it into very similar D just like 
https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/


D has the size of long fixed at 64 bits, so a pointer now has to 
be 64 bits. So I want to put something into the source to ensure 
an attempt to make a 32 bit build fails. What is the best way to 
do this?


GtkD CRUD Application

2020-10-17 Thread Alaindevos via Digitalmars-d-learn

I've written the beginning but dont know how to end.
What is the way to add functionality for the add,edit,delete 
button ?

//==
import gtk.Button;
import gtk.Box;
import gtk.Label;
import gtk.Entry;
import gtk.Grid;
import gtk.Main;
import gtk.MainWindow;
import gtk.Widget;
import gdk.Event: Event;
import std.array: assocArray;
import std.conv: to;
import std.format : format;
import std.range: iota, retro, drop, zip;
import std.stdio: writeln;



struct nameage {
string name;
int age;
}

class Row: Box {
ulong index;
this(nameage anameage,ulong index){
this.index=index;
super(Orientation.HORIZONTAL,5);
this.packStart((new Label(anameage.name)),0,0,0);
this.packStart((new Label(to!string(anameage.age))),0,0,0);
this.packStart((new Button("Edit")),0,0,0);
this.packStart((new Button("Delete")),0,0,0);

}
}

class MyWindow : MainWindow {

Box vbox;
nameage []mynameage;

void quit(){
this.quit();
}

void addclicked(){
}

this(int sizex,int sizey){
nameage nameage1=nameage("Alain",20);
nameage nameage2=nameage("Eddy",30);
mynameage ~= nameage1;
mynameage ~= nameage2;
super("My Locate D-lang App");
setSizeRequest(sizex,sizey);
setHexpand(0);
addOnDestroy(delegate void(Widget w) { quit(); } );
vbox=new Box(Orientation.VERTICAL,5);
foreach (ulong i,anameage;mynameage){
Row arow=new Row(anameage,i);
vbox.packStart(arow,0,0,0);
}
Button addbutton=new Button("Add");
addbutton.addOnClicked(delegate void(Button 
b){addclicked();});
vbox.packStart(addbutton,0,0,0);

add(vbox);
showAll();
}
}


int main(string[] args){
int sizex=800;
int sizey=600;
Main.init(args);
MyWindow window=new MyWindow(sizex,sizey);
Main.run();
return 0;
}
//==



Re: vibe.d / experience / feedback

2020-10-17 Thread aberba via Digitalmars-d-learn

On Wednesday, 14 October 2020 at 15:11:29 UTC, Alaindevos wrote:
Is there an example just more functional then skeleton http 
server ?

Sending data to the server and back .


If you're having vibe.d trouble and can't get a quick response, 
jump in the discord. We're there to help?


Re: Packing of Struct Fields

2020-10-17 Thread Steven Schveighoffer via Digitalmars-d-learn

On 10/17/20 9:00 AM, Per Nordlöw wrote:

On Saturday, 17 October 2020 at 12:51:21 UTC, ag0aep6g wrote:
c does come directly after s. The padding between b and c is part of 
s. If you don't want that padding, you can use `align(1)` to define S 
without padding. But then 75% of the ints in an S[] will be misaligned.


I understand that. I don't want the alignment of `S` to change. I want 
the padding after `s` in `T` to be avoided and have `c` start at 
byte-offset 7. I don't see why this padding is needed in the case where 
only a single (1-element array of) `S` is stored as a field inside 
another aggregate.


Ali's code prints:

=== Memory layout of 'T' (.sizeof: 12, .alignof: 4) ===
    0: S s
    8: char c
    9: ... 3-byte PADDING


There might be some good reasons for this.

For one, what happens if you copy the s? Does it copy the c too?

For another, this is how C does it, so I would expect it to at least 
match C for compatibility.


I think it *should* be possible to do this, if it's not already, just 
with pragmas. (i.e. pack T but not S).


-Steve


Re: How do I use translation module in vibe.d?

2020-10-17 Thread aberba via Digitalmars-d-learn

On Tuesday, 13 October 2020 at 17:02:54 UTC, Jack wrote:

On Tuesday, 13 October 2020 at 08:07:17 UTC, aberba wrote:

On Friday, 9 October 2020 at 21:07:28 UTC, jack wrote:

[...]


https://www.github.com/vibe-d/vibe.d/tree/master/examples%2Fweb-i18n

There's also an example here


My dub.json file and folder structure is exactly this one, as 
the tutorial told to do yet I get the compilation error. I 
guess the library was updated but the documentation didn't


I'll have to try that. I haven't really used vibe.d translation 
myself beyond learning... and that was a long time ago.


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 17 October 2020 at 13:23:38 UTC, Adam D. Ruppe wrote:

Use a union.


Nice! Thanks!


Re: Packing of Struct Fields

2020-10-17 Thread Adam D. Ruppe via Digitalmars-d-learn

On Saturday, 17 October 2020 at 13:00:59 UTC, Per Nordlöw wrote:
I understand that. I don't want the alignment of `S` to change. 
I want the padding after `s`


That padding is part of S. It is at the end, after its fields, 
but still part of it.


S's layout doesn't depend on what else is around it.


in `T` to be avoided and have `c` start at byte-offset 7.


Use a union.

struct S
{
int i;  // 4 bytes
short s;// 2 byte
bool b; // 1 byte
}
static assert(S.sizeof == 8);
static assert(S.alignof == 4);

struct T {
   union {
   S s;
   struct {
   align(1):
   ubyte[7] _ignore_me;
   char c;
   }
   }
}

static assert(T.alignof == 4);
static assert(T.sizeof == 8);
static assert(T.c.offsetof == 7);



Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 17 October 2020 at 12:51:21 UTC, ag0aep6g wrote:
c does come directly after s. The padding between b and c is 
part of s. If you don't want that padding, you can use 
`align(1)` to define S without padding. But then 75% of the 
ints in an S[] will be misaligned.


I understand that. I don't want the alignment of `S` to change. I 
want the padding after `s` in `T` to be avoided and have `c` 
start at byte-offset 7. I don't see why this padding is needed in 
the case where only a single (1-element array of) `S` is stored 
as a field inside another aggregate.


Ali's code prints:

=== Memory layout of 'T' (.sizeof: 12, .alignof: 4) ===
   0: S s
   8: char c
   9: ... 3-byte PADDING


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 17 October 2020 at 12:44:44 UTC, Per Nordlöw wrote:
Can `align`s be inserted in S or/and T so that T is packed to 8 
bytes but still aligned to 8 bytes? I don't see why this 
shouldn't be the default behaviour...


I though this would do the trick but not...

struct S
{
int i;  // 4 bytes
short s;// 2 byte
bool b; // 1 byte
}
static assert(S.sizeof == 8);
static assert(S.alignof == 4);
align(4) struct T
{
align(4) S s;
align(1) char c;
}
static assert(T.alignof == 4);
// TODO: static assert(T.sizeof == 8);

T.sizeof is still 12 bytes, I want it to be 8.


Re: Packing of Struct Fields

2020-10-17 Thread ag0aep6g via Digitalmars-d-learn

On 17.10.20 14:35, Per Nordlöw wrote:

struct S
{
     int i;
     bool b;
}

struct T
{
     S s; // reinterpreting this as an array can only access this first 
element anyway
     char c; // so why can't this be aligned directly after `s` without 
any padding?

}



c does come directly after s. The padding between b and c is part of s. 
If you don't want that padding, you can use `align(1)` to define S 
without padding. But then 75% of the ints in an S[] will be misaligned.


Re: Packing of Struct Fields

2020-10-17 Thread Adam D. Ruppe via Digitalmars-d-learn

On Saturday, 17 October 2020 at 12:44:44 UTC, Per Nordlöw wrote:
Can `align`s be inserted in S or/and T so that T is packed to 8 
bytes but still aligned to 8 bytes?


Yes. Put an align on the OUTSIDE of the struct you are nesting, 
then put one INSIDE the struct you want the contents packed.



I don't see why this shouldn't be the default behaviour...


It is generally slower.


Re: Why is `Appender._data` a pointer to its `Data`-store?

2020-10-17 Thread Steven Schveighoffer via Digitalmars-d-learn

On 10/17/20 12:00 AM, Paul Backus wrote:

On Saturday, 17 October 2020 at 00:06:31 UTC, Steven Schveighoffer wrote:


Appender is ref counted IIRC.



It's not; it uses the GC.


Oh yeah. In fact, it was me who did that (in 2010!).

My point should have been that the appender is a pImpl to avoid memory 
corruption. If you have multiple copies of an appender, and each has its 
own idea of what the capacity is, then you will get corruption.


See the original bug report here: 
https://issues.dlang.org/show_bug.cgi?id=4681


-Steve


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 17 October 2020 at 12:35:37 UTC, Per Nordlöw wrote:
On Friday, 16 October 2020 at 21:26:12 UTC, Steven 
Schveighoffer wrote:
To further explain this -- the padding is added so things like 
pointer arithmetic on an array work.


In my code sample above one can only access the first element 
anyhow so I don't understand why this restriction is imposed 
here.


struct S
{
int i;
bool b;
}

struct T
{
S s; // reinterpreting this as an array can only access 
this first element anyway
char c; // so why can't this be aligned directly after `s` 
without any padding?

}


So AFAICT the key question becomes:

Can `align`s be inserted in S or/and T so that T is packed to 8 
bytes but still aligned to 8 bytes? I don't see why this 
shouldn't be the default behaviour...


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn
On Friday, 16 October 2020 at 21:26:12 UTC, Steven Schveighoffer 
wrote:
To further explain this -- the padding is added so things like 
pointer arithmetic on an array work.


In my code sample above one can only access the first element 
anyhow so I don't understand why this restriction is imposed here.


struct S
{
int i;
bool b;
}

struct T
{
S s; // reinterpreting this as an array can only access this 
first element anyway
char c; // so why can't this be aligned directly after `s` 
without any padding?

}



Re: Struct field destructor not called when exception is thrown in the main struct destructor

2020-10-17 Thread tchaloupka via Digitalmars-d-learn
On Friday, 16 October 2020 at 16:00:07 UTC, Steven Schveighoffer 
wrote:

On 10/16/20 9:12 AM, tchaloupka wrote:

So when the exception is thrown within Foo destructor (and 
it's bad on it's own but can easily happen as destructors 
aren't nothrow @nogc by default).


Is this behavior expected?


I would say it's a bug. The compiler is going to call the 
member destructor even if the hand-written destructor does it 
too. If the compiler wants to take responsibility for cleaning 
up members, it should take full responsibility. In fact, there 
is no way to instruct the compiler "I'm handling the 
destruction of this member", so I don't see why it should 
matter if you exit the function via exception it should be any 
different.


-Steve


Thx, added https://issues.dlang.org/show_bug.cgi?id=21322


Re: How to rebind the default tkd GUI keybinds?

2020-10-17 Thread tastyminerals via Digitalmars-d-learn

On Sunday, 11 October 2020 at 18:51:17 UTC, tastyminerals wrote:
Tk default keys are somewhat different from what we used to use 
for selecting, copying and pasting the text. So, any Tk based 
GUI app starts with writing the rebinding function for 
"ctrl+a", "ctrl+c", "ctrl+x" and "ctrl+v" keys, at least. I did 
it when writing TkInter based apps in Python. Today I am trying 
out tkd and want to do the same. However, it doesn't work :(


For example:

private void selectText(CommandArgs args) {
this._clientId.selectText;
}

this._loginFrame = new Frame(2, ReliefStyle.groove);
this._clientId = new Entry(loginFrame).grid(1, 0);
this._clientId.bind("", );

It works if I change "" to "" for example.
But how do I overwrite the actual "" key in tkd?


So, this is even tricky in Python TkInter but possible.
In tkd this is not possible unfortunately.