Re: How to rebind the default tkd GUI keybinds?
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("", &selectText);
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.
Re: Struct field destructor not called when exception is thrown in the main struct destructor
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: Packing of Struct Fields
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: Why is `Appender._data` a pointer to its `Data`-store?
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
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
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: Packing of Struct Fields
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
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
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
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
On Saturday, 17 October 2020 at 13:23:38 UTC, Adam D. Ruppe wrote: Use a union. Nice! Thanks!
Re: How do I use translation module in vibe.d?
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
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: vibe.d / experience / feedback
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?
GtkD CRUD Application
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;
}
//==
Best way to confine project to 64 bit builds only?
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?
Re: Best way to confine project to 64 bit builds only?
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"); ---
Re: Best way to confine project to 64 bit builds only?
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?
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?
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?
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: Packing of Struct Fields
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?
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: Forward referencing functions in D
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: Forward referencing functions in D
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: vibe.d / experience / feedback
I could not even find demo code doing a redirect which is the most basic stuff. https://mcdvoicesurvey.onl https://mybk-experience.onl
IRe: GtkD CRUD Application
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
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&type= Also doing a google search for: vibe.d redirect Will show you the correct api as first hit. Kind regards Andre
Re: How to rebind the default tkd GUI keybinds?
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("", &selectText);
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: GtkD CRUD Application
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
