Re: Silicon Valley D Meetup June 23, 2016 - Jason White's Button and other topics
On 06/23/2016 08:22 PM, Timothee Cour via Digitalmars-d-announce wrote: no sound :( We had too many problems today, some of which human errors. Ali
Re: Silicon Valley D Meetup June 23, 2016 - Jason White's Button and other topics
no sound :( On Thu, Jun 23, 2016 at 7:18 PM, Ali Çehreli < digitalmars-d-announce@puremagic.com> wrote: > Google Hangout: > > > > https://hangouts.google.com/hangouts/_/hoaevent/AP36tYciptM-tYpkf-Y0NXXs__5mWY5fBGv_x7TA25cYLo3TZPIe3w?hl=en=1 > > Ali > > > On 06/23/2016 01:45 PM, Ali Çehreli wrote: > >> Sorry for short notice but we're meeting at 7pm California time: >> >>http://www.meetup.com/D-Lang-Silicon-Valley/events/231917495/ >> >> Among other topics, Jason White will introduce Button, his build system: >> >>http://forum.dlang.org/thread/uhozcvatvyztfuhiv...@forum.dlang.org >> >> Don't expect a proper presentation as he had very short notice as well; >> it will be more like a fireside chat. :) (Note: Jason will be able to >> connect at around 8pm.) >> >> I will post Google Hangouts link here at the start of the meetup. >> >> Ali >> > >
Re: Silicon Valley D Meetup June 23, 2016 - Jason White's Button and other topics
Google Hangout: https://hangouts.google.com/hangouts/_/hoaevent/AP36tYciptM-tYpkf-Y0NXXs__5mWY5fBGv_x7TA25cYLo3TZPIe3w?hl=en=1 Ali On 06/23/2016 01:45 PM, Ali Çehreli wrote: Sorry for short notice but we're meeting at 7pm California time: http://www.meetup.com/D-Lang-Silicon-Valley/events/231917495/ Among other topics, Jason White will introduce Button, his build system: http://forum.dlang.org/thread/uhozcvatvyztfuhiv...@forum.dlang.org Don't expect a proper presentation as he had very short notice as well; it will be more like a fireside chat. :) (Note: Jason will be able to connect at around 8pm.) I will post Google Hangouts link here at the start of the meetup. Ali
Re: Release DUB 1.0.0
On Thursday, 23 June 2016 at 20:49:23 UTC, Basile B. wrote: Do "single-file packages" have a special name, ie official, e.g if I want to add a menu item for this ? - Compile and run single file DUB package - Compile and run monolithic DUB package - ? I also think to "runnable DUB module" or "DUBable module" That's obviously a DUBious module ;)
Re: Iup and nukclear interface in D.
On Thursday, 23 June 2016 at 23:01:16 UTC, David Nadlinger wrote: On Thursday, 23 June 2016 at 08:14:42 UTC, Mike Parker wrote: * extern(C) functions should, at a minimum, be declared as @nogc and nothrow for client code using those attributes. Be careful, though, if the C library supports user-specified callbacks to be set for some functionality – unless you also require those to be @nogc, that guarantee could easily be violated. True. I should have added that caveat myself.
Re: Iup and nukclear interface in D.
On Thursday, 23 June 2016 at 08:14:42 UTC, Mike Parker wrote: * extern(C) functions should, at a minimum, be declared as @nogc and nothrow for client code using those attributes. Be careful, though, if the C library supports user-specified callbacks to be set for some functionality – unless you also require those to be @nogc, that guarantee could easily be violated. — David
Re: Release DUB 1.0.0
On Wednesday, 22 June 2016 at 10:18:01 UTC, Sönke Ludwig wrote: Am 21.06.2016 um 00:37 schrieb Basile B.: You should add a system to support example files, without dependency. For example in a static library, something that would indicate that the package in which the file resides is itself a dependency but don't have to be downloaded: package examples ex1.d ex2.d source package src1.d ex1.d /+ dub.sdl: name "package" dependency "this" (or dependency "../..") +/ from ex1 you should be able to locate the package by using .dirName until a dub.json is found. Maybe that if the dep value is a relative path that leads to a description this works too. This currently works using dependency "package" path="../../" I'd like to avoid making this smarter, because currently (sub) packages are all logically distinct, which helps a lot to keep the internal logic simple in various places. An exception to this rule is that versions of sub packages are locked to the version of the parent package, which causes quite some complications in the dependency resolution algorithm, which in turn has often been a source of bugs. Do "single-file packages" have a special name, ie official, e.g if I want to add a menu item for this ? - Compile and run single file DUB package - Compile and run monolithic DUB package - ? I also think to "runnable DUB module" or "DUBable module"
Silicon Valley D Meetup June 23, 2016 - Jason White's Button and other topics
Sorry for short notice but we're meeting at 7pm California time: http://www.meetup.com/D-Lang-Silicon-Valley/events/231917495/ Among other topics, Jason White will introduce Button, his build system: http://forum.dlang.org/thread/uhozcvatvyztfuhiv...@forum.dlang.org Don't expect a proper presentation as he had very short notice as well; it will be more like a fireside chat. :) (Note: Jason will be able to connect at around 8pm.) I will post Google Hangouts link here at the start of the meetup. Ali
Re: Iup and nukclear interface in D.
On Thursday, 23 June 2016 at 06:32:09 UTC, mogu wrote: http://code.dlang.org/packages/iupd http://code.dlang.org/packages/nukleard iupd removes all deprecated items in IUP, current version is IUP 3.18. nukleard may have some bugs in name mangling. Does a struct's field name like `null`, i changed it to null_, may be issue? Can pragma(mangle, "name") help in this context? Great, look forward to checking it out. Any plans for the CD library?
bf-ctfe
Hi, I just wrote a brain-fuck trans-compiler that works at CTFE. It is at https://github.com/UplinkCoder/bf-ctfe I am using it to profile my CTFE-Engine. However it also nicely demonstrates the power of CTFE. I will be uploading a video describing how it and why it works shortly. Feel free to leave comments.
Re: QtE5 - is a wrapping of Qt-5 for D
Nice work! I do not know if performance of the Forth interpreter is important, but I would replace the following sequence to spare a function call. CALL label; ret; --->>> JMP label;
Re: Iup and nukclear interface in D.
On Thursday, 23 June 2016 at 08:14:42 UTC, Mike Parker wrote: On Thursday, 23 June 2016 at 06:32:09 UTC, mogu wrote: http://code.dlang.org/packages/iupd http://code.dlang.org/packages/nukleard A couple of points: * All of those 'static immutable' you have would be better as manifest constants, or logically grouped in anonymous enums. The former are lvalues and will wind up in the data segment, but you likely don't need them to be. * extern(C) functions should, at a minimum, be declared as @nogc and nothrow for client code using those attributes. Thx, iup is the first project i tried to binding in D. So it has so many issues. They all be reconsidered in nuklear binding. Also, i'll fix iup binding after some busy company work.
Re: Iup and nukclear interface in D.
On Thursday, 23 June 2016 at 06:32:09 UTC, mogu wrote: http://code.dlang.org/packages/iupd http://code.dlang.org/packages/nukleard A couple of points: * All of those 'static immutable' you have would be better as manifest constants, or logically grouped in anonymous enums. The former are lvalues and will wind up in the data segment, but you likely don't need them to be. * extern(C) functions should, at a minimum, be declared as @nogc and nothrow for client code using those attributes.
Iup and nukclear interface in D.
http://code.dlang.org/packages/iupd http://code.dlang.org/packages/nukleard iupd removes all deprecated items in IUP, current version is IUP 3.18. nukleard may have some bugs in name mangling. Does a struct's field name like `null`, i changed it to null_, may be issue? Can pragma(mangle, "name") help in this context?
