Re: Opportunities for D
On 09/07/14 00:21, bearophile wrote: 9. Built-in tuples usable in all the most important situations (with a syntax that doesn't kill possible future improvements of the switch statement to perform basic pattern matching on structs that have an optional method named "unapply"). I think it would be possible to implement pattern matching in library code. Something like this: match!(value, (int t) => ifInt(), (char t) => ifChar(), () => noOtherMatch() ); Destructing a type could look something like this: match(value, (type!(Foo), int a, int b) => doSomething(), // match if value is of type Foo and extract it (int a, int b) => doSomething() // match anything that can be destructed to two ints ); The syntax is not so pretty but I think it would be possible. -- /Jacob Carlborg
Re: Opportunities for D
On 7/8/2014 10:00 PM, H. S. Teoh via Digitalmars-d wrote: On Tue, Jul 08, 2014 at 07:42:50PM -0700, Walter Bright via Digitalmars-d wrote: On 7/8/2014 3:37 PM, bearophile wrote: Walter Bright: 3. 'ref' means 'borrowed', to use Rust's terminology We're almost there with this. This means better escape analysis, too. Is "scope" still left for future usage, or used for a different purpose, or deprecated? That would have to be addressed as part of this. Does that mean that finally 'scope' will work as advertised? I've been waiting for that for a long time. Help is welcome working on a design.
Re: Opportunities for D
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 5. Precise and Concurrent GC There's been a lot of work on this, but I don't know where we stand on it. The precise work is held up by: https://github.com/D-Programming-Language/dmd/pull/2480 The GC is due for a redesign / reimplementation.
Re: DIP65: Fixing Exception Handling Syntax
On Wednesday, 9 July 2014 at 02:48:03 UTC, Walter Bright wrote:
On 7/8/2014 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to
fix them. It will
break some poorly-written code, but I think I can automate the
upgrade process.
I don't want to break existing code. The grammar ambiguity
issue can be resolved by the user as:
catch (A) { .someFunction(); }
There is no ambiguity in the grammar. "catch (A) { ... }" is not
valid. The spec requires that you give the exception a name. A
spec compliant D compiler MUST parse your example code with the
LastCatch rule. The fact that DMD does what it does is a bug that
has been documented for over a year.[1]
Implementing the spec, i.e. requiring exceptions to be named,
would break far more code than what I propose.[3] If we want to
have nameless exceptions, we need to change the specification to
make the name optional. If we do that, the grammar becomes
ambiguous. To fix the ambiguity we must either remove the
LastCatch rule from the language spec[2] or introduce a rule for
NoScopeNonEmptyStatement-that-doesn't-start-with-parens.
[1] https://issues.dlang.org/show_bug.cgi?id=10247
[2] https://issues.dlang.org/show_bug.cgi?id=12558
[3] I don't know how people uncover these undocumented features
and build important code with them.
Re: Bottom line re GC in D
Hi folks, Thank you all for your very informative answers - much appreciated. Great to see such an active community there. To summarise what you said: + No, the GC can't be taken out, but with careful attention one can - relatively easily - bypass it. This can come at a price of some great features of the language, but then if the requirement is to not use the GC one can do so. This is perhaps flexibility no? + The current GC will be improved, but it's taking some time for that to happen - which is a shame, for if the GC is stumbling block for some people (such as myself), an inefficient/weak one does not help in convincing GC sceptics to accept it. + The @nogc stuff and work you mentioned with the standard library is also encouraging. Now, going forward, is there a comprehensive and precise set of instructions available that one could follow in order to write D programs entirely devoid of the GC? That would be most helpful if available. Once again, thank you all. - Adrian.
Re: Bottom line re GC in D
Adrian: for if the GC is stumbling block for some people (such as myself), an inefficient/weak one does not help in convincing GC sceptics to accept it. ... is there a comprehensive and precise set of instructions available that one could follow in order to write D programs entirely devoid of the GC? Have you written enough D code where you have seen the current GC is not good enough for you? How much good has to be the D GC for you to use it? Bye, bearophile
Re: Opportunities for D
Meta: What if we had an "opDestructure" or "opMatch" or something like that? It could return a tuple and be auto-implemented by the compiler for simple structs/classes. Then users could precisely control how their type can be destructured. The optional "unapply" method is from the Scala language, and it's more or less what you are suggesting, with a different name (and I agree opSomething sounds like a more fitting name for D). Such opMatch has optional arguments too, because you can match in different ways. Bye, bearophile
Re: Opportunities for D
On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote: On 7/8/2014 6:01 PM, Mike wrote: On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 1. Ref Counting I believe that ARC is a pipe dream for D, as we've discussed extensively here. But a ref counted object should work, and would be very attractive, much like C++'s shared_ptr. How does this differ from std.typecons.RefCounted? Let me put it this way: users all complain that D doesn't have ref counting. If typecons.RefCounted works, why is this happening? What can be done to convince people that D does ref counting? If it doesn't work, what needs to be done to fix it? I think the problem is that people like to have reference semantics for ressources but only struct support deterministic destruction, and are value types.. If Unique and RefCounted were a bit more usable people interested in deterministic release (ie. almost everyone) could drop using classes for resources and live happily.
Re: Opportunities for D
(and I agree opSomething sounds like a more fitting name for D). Added your names: https://issues.dlang.org/show_bug.cgi?id=596 Bye, bearophile
Re: Opportunities for D
Walter Bright: The list isn't about things that would be nice to add to D, it's about fairly critical issues with large impact we need to address. More on tuples and pattern matching are not critical issues. In this thread I have asked for just tuples, not pattern matching (I have just said that tuples design should not make it very hard to add a basic but nice form of pattern matching later in the switch statement). Regarding NotNull (your point 8), I think what's more important is to make it statically impossible for the programmer to dereference a null for a nullable type. (To do this some languages use pattern matching, that forces the programmer to handle both cases (null and not null), and in the case of not null, the programmer is handling something similar to a NotNull). Bye, bearophile
Re: critique of vibe.d
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: "has anyone ever tied a real webservice to vibe.d?" Yes and see no problems with it. Looks like author has very specific expectations of "webservice" concept and can't do a thing with 100%
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 09:47:21 UTC, Dicebot wrote: On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: "has anyone ever tied a real webservice to vibe.d?" Yes and see no problems with it. Looks like author has very specific expectations of "webservice" concept and can't do a thing with 100% .. coverage of all utilities in the library. Sad he does not provide some sample of missing bits. Most likely he has expected vibe.d to be exclusively web framework while it is generic networking / async framework.
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote: Vibe.d is more like a base library for async I/O, networking and concurrency, a full stack WEB framework should be built on top of it Ironically I find pure vibe.d solutions much more clean and easy to maintain than any enhancements built on top so far (including Cmsed). I don't do any frontend stuff though.
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 20:40:02 UTC, Walter Bright wrote: On 7/8/2014 1:39 PM, Walter Bright wrote: This is all great news, congratulations! On the gc-sections front, Martin had gotten it to work for DMD on Linux but then had to back it out because it failed with the ld.gold linker. If it works for ldc with ld.gold, can you please help explain what went wrong for dmd? https://github.com/D-Programming-Language/dmd/pull/3715 If you pay attention to my comment there, original PR has never actually changed a single bit about generated binaries :(
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 17:54:48 UTC, David Nadlinger wrote:
Hi all,
I am excited to share news about two changes that recently made
their way into the development version of LDC, changes that
might be interesting for many of you Linux users out there.
The first is that LDC now supports linker-level dead code
elimination on Linux. If you happen to be familiar with the
-f{function,data}-sections/--gc-sections options of the GNU
toolchain, their equivalent is now enabled by default. For a
set of small-ish programs that make use of different parts of
Phobos, I've seen executable size improvements of close to 4x
(!) in my tests. However, as --gc-sections is known to
occasionally cause trouble with third-party code that relies on
specific linker behavior, this optimization can be disabled
with a new LDC switch, -disable-linker-strip-dead.
And secondly, proper support for building druntime/Phobos as
shared libraries and loading D shared objects dynamically has
now arrived in LDC! As you might be aware, Martin Nowak has
spent a considerable amount of effort on adding runtime loading
capabilities to DMD and druntime during the last year or so.
LDC now offers the same level of functionality, to a good part
based on Martin's solid work. To build a copy of LDC with
druntime/Phobos as a shared library, which is also required for
proper runtime loading, simply pass -DBUILD_SHARED_LIBS=ON to
CMake. Oh, and for now this is Linux-only too, sorry.
Even though I am currently not aware of any remaining issues,
there are likely a few rough edges still. To be able to
confidently ship these features as part of the next release,
we'd very much appreciate early feedback. Just grab LDC from
Git master and let us know how things went over on
digitalmars.D.ldc. If you run into a specific bug, you can also
directly open a ticket at
https://github.com/ldc-developers/ldc/issues.
Cheers,
David
Those are probably best news from D world I have heard in last
few months! Has anyone tried that on largish projects? Using GDC
with --gc-sections has resulted in broken binaries sometimes but
most likely it was the same ModuleInfo issue. Wonder how reliable
it is in LDC.
Re: Opportunities for D
Some minor disagreements: On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 2. Unique References unique_ptr is another big success for C++. 2.066 has already made big strides in inferring uniqueness of expressions, but it doesn't go so far as creating a Unique!T type. http://dlang.org/phobos/std_typecons.html#.Unique 3. 'ref' means 'borrowed', to use Rust's terminology We're almost there with this. This means better escape analysis, too. Last time we talked about it during dconf you have mentioned doing necessary escape analysis for borrowing semantics is too complicated to consider :) Ad if you don't mean transitive, you shouldn't refer to Rust borrowing terminology as any ownership type is normally transitive there. 5. Precise and Concurrent GC There's been a lot of work on this, but I don't know where we stand on it. I have started work on porting the CDGC to D2, have compilable version (that was easy thanks to earlier Sean work) but updating implementation to match new druntime and pass tests will take quite some time. 7. "D-Routines" - goroutines for D Goroutines are the killer feature of Go for a number of sensible people. We pretty much have this already with fibers, but what is lacking is a scheduler, which will take some effort, and a "Channel" type, which should be easy. I'd state it differently: "Marketing fuss about goroutines is the killer feature of Go" :) It does not have any fundamental advantage over existing actor model and I doubt it will matter _that_ much. 8. NotNull!T type For those that want a non-nullable reference type. This should be doable as a library type. I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one.
Re: Opportunities for D
On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote: On 7/8/2014 6:01 PM, Mike wrote: On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 1. Ref Counting I believe that ARC is a pipe dream for D, as we've discussed extensively here. But a ref counted object should work, and would be very attractive, much like C++'s shared_ptr. How does this differ from std.typecons.RefCounted? Let me put it this way: users all complain that D doesn't have ref counting. If typecons.RefCounted works, why is this happening? What can be done to convince people that D does ref counting? If it doesn't work, what needs to be done to fix it? For me the simple "works or not" test question is "can you do reference counted exceptions?". Right now it is impossible AFAIK.
Re: Bottom line re GC in D
Have you written enough D code where you have seen the current GC is not good enough for you? How much good has to be the D GC for you to use it? Bye, bearophile Hi, As I said at the start, I have been away a while but I wrote a fair amount of code in D about a year ago to test the waters. From my experience of those tests, I mainly targeted the GC and if I remember well, I had written code that, based on command line switches, specified if the incorporated GC is to be used for memory allocation/deallocation or whether memory is done entirely manually (I managed this through some posts in the forum where community members instructed me how to achieve this). From my limited tests, the ones which used manual memory management ran in roughly half the time; the GC ones took almost double the time and in some cases more than that. I don't have the code at hand (I might need to dig it out), but I certainly can vouch for a significant discrepancy in performance between the GC versions and manual versions. So yes, this is a significant issue (i.e. the current GC is not good enough for me and I cannot overlook it). As for your second question (i.e. how good the GC needs to be for me), I would probably be satisfied with a GC that matches the Java one (used in conjunction with D's ability to take over memory management completely in the critical parts where needed) - but admittedly, I don't know the implications in achieving that within D's memory model, etc. I am embarking on a start-up pretty soon and I have been looking at possible languages/frameworks to use; I've looked at Go in detail, had a cursory look (so far) at Rust and have also used to a fair degree. D is the most natural fit for me and my team coming from a mainly C++ and Java background, but I would really like to make an informed decision vis-a-vis the GC implications. Thanks for your help. - Adrian.
Re: Worrying attitudes to the branding of the D language
On 02/07/2014 10:10 PM, Alix Pexton wrote: On 02/07/2014 6:13 PM, Vladimir Panteleev wrote: On Wednesday, 2 July 2014 at 16:53:52 UTC, Brad Anderson wrote: He should be contacted and asked if he'd be willing to assign copyright to Walter. Does anyone have his email address? Walter and I have attempted to reach out to Martin a while ago with regards to logo licensing (triggered by the logo's deletion on Wikipedia - it was taken down once, but since then someone reuploaded it again). As far as I know, so far there has been no reply. Here's the information I have: Original post: http://forum.dlang.org/post/e3j72u$16n7$1...@digitaldaemon.com GitHub profile: https://github.com/FunkyM Professional website: http://mirell.de/ The site where the original logo is hosted has a "mail me" link on its landing page... heyitsal...@sukimashita.com A... Has anyone made a new attempt to reach out to Martin yet? A...
Re: Bottom line re GC in D
Adrian: As for your second question (i.e. how good the GC needs to be for me), I would probably be satisfied with a GC that matches the Java one This will not happen even in one hundred years. So if that's what you want, you will never be satisfied by D GC. Bye, bearophile
Re: Redesign of dlang.org
On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via Digitalmars-d wrote: On 8 July 2014 21:20, deadalnix via Digitalmars-d wrote: On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote: […] Powered by Martian Technology @SarcasticRover is telling us "Do not come to Mars." Perhaps its commentary need censoring ;-) He also get angry when you mention that using the imperial system is idiotic. But the imperial system *isn't* idiotic. :o) And everyone should drive on the left. Driving on the left goes back to the times when coaches (carriages) were still in use. This was to avoid that drivers would accidentally hit each other with their whips when a coach would come from the opposite direction. No joke. As regards cars, driving on the left is highly unintuitive for most people as the majority of drivers are right-handed. There is no ergonomic or technical reason why cars should drive on the left. In most parts of the world driving on the right was adopted from early on as it is more intuitive (for most people).
Re: Bottom line re GC in D
On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote: Adrian: As for your second question (i.e. how good the GC needs to be for me), I would probably be satisfied with a GC that matches the Java one This will not happen even in one hundred years. So if that's what you want, you will never be satisfied by D GC. Uhmm... what makes you think so?
Re: Bottom line re GC in D
On Wednesday, 9 July 2014 at 11:44:31 UTC, Marc Schütz wrote: This will not happen even in one hundred years. So if that's what you want, you will never be satisfied by D GC. Uhmm... what makes you think so? Good question actually...
Re: @nogc and NSAutoReleasePool-style regions.
On Tuesday, 8 July 2014 at 21:17:50 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 8 July 2014 at 20:38:59 UTC, Marc Schütz wrote: But as you already noted, there needs to be a mechanism to restrict escaping of pointers. Yes, there ought to be, at least for @safe code. Do you have some concrete idea how that could be solved? For my use, yes. Since I am considering a D-version for game server development that does whole program analysis and might put additional restrictions on the language. I'd like to restrict the language to the extent that I can generate C code for portability (server/client code sharing)… However, it should be possible with more local annotations too, but maybe the existing ones that D provides are too weak or too strong? One needs to prevent escaping, that means: 1. prevent writing through global variables (but allow reading values, but not reading references for writing?) 2. prevent establishing new global contexts (threads and fibers) 3. putting limitations on the in-parameters to functions called within the region-allocator block so they don't allow writing to global contexts 4. ??? Sounds a lot like "pure", but not quite matching up? Well, `scope` was supposed to be that, but it's unimplemented and not completely thought through. A more or less straight-forward way would be to encode the ownership/lifetime information somewhere in the types of the pointers (similar to how we use const and the like today). But this cannot be done, because it could not apply to external (non-template) functions. It would be nice if it could fit into the current infrastructure… but all suggestions are interesting. I think it could be a nice way to get "gc" level convinience during spin up of a server when you have plenty of memory available (you can afford to be wasteful before you load in the main data). Thinking aloud: If we could distinguish GC pointers from non-GC pointers, we could apply the ownership information to them "after the fact". Any GC pointer that comes out from your library functions inside an auto-release block can be confined to inside that block, or to the lifetime of the allocator. (That is, only _newly allocated_ GC pointers inside those blocks...)
Re: @nogc and NSAutoReleasePool-style regions.
On Wednesday, 9 July 2014 at 12:01:12 UTC, Marc Schütz wrote: Sounds a lot like "pure", but not quite matching up? Well, `scope` was supposed to be that, but it's unimplemented and not completely thought through. *nods* Thinking aloud: If we could distinguish GC pointers from non-GC pointers, we could apply the ownership information to them "after the fact". Any GC pointer that comes out from your library functions inside an auto-release block can be confined to inside that block, or to the lifetime of the allocator. (That is, only _newly allocated_ GC pointers inside those blocks...) For the @nogc+region allocator GC pointers could be helpeful. And as I tried to point out in another thread on GC performance, it could also provide precise GC collection performance benefits if you also clustered the GC pointers in objects at a negative offset (thus getting them onto the same cachelines even though they originate in deep sub-classes as well as super.classes). Another benefit with explicit GC pointers is that you could ban GC pointers to classes that provide destructors, sanitizing the constructor/destructor situation.
Re: DIP65: Fixing Exception Handling Syntax
On 7/9/14, Brian Schott via Digitalmars-d wrote:
> There is no ambiguity in the grammar. "catch (A) { ... }" is not
> valid.
Give it a rest. If 'void foo(int, float)' is ok so should 'catch (E)'
be. We can change the spec if we have to, it's easier than breaking
code.
Re: DIP65: Fixing Exception Handling Syntax
On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via Digitalmars-d wrote: Give it a rest. If 'void foo(int, float)' is ok so should 'catch (E)' be. We can change the spec if we have to, it's easier than breaking code. Huh? Brian explicitly remarked earlier that Implementing the spec, i.e. requiring exceptions to be named, would break far more code than what I propose, and the DIP doesn't contain anything to that effect either I'm a bit puzzled as to what the controversy is supposed to be about. David
Re: DIP65: Fixing Exception Handling Syntax
On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 7/9/14, Brian Schott via Digitalmars-d
wrote:
There is no ambiguity in the grammar. "catch (A) { ... }" is
not
valid.
Give it a rest. If 'void foo(int, float)' is ok so should
'catch (E)'
be. We can change the spec if we have to, it's easier than
breaking
code.
I think Brian is being quite gracious with his proposal. The
offer to automate fixing users' code is especially generous.
Mike
Re: Bottom line re GC in D
Marc Schütz: Uhmm... what makes you think so? The huge amount of work done on the OracleVM GC that is not easy to match. D need for low-level code (currently user code can't tell the GC what are the current actual contents of a union, this includes Algebraic), D desire to interface efficiently to C code. Bye, bearophile
Re: Opportunities for D
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 3. 'ref' means 'borrowed', to use Rust's terminology We're almost there with this. This means better escape analysis, too. IMO this is not good, because it should be applicable for pointers, classes and slices, too (and structs containing any of them, of course). If you use `ref` with these, an extra layer of indirection is introduced, which also changes the semantics, e.g. for non-const pointers the original pointer can suddenly be overwritten. `scope` is much better suited for borrowing, because it's orthogonal to `ref`. 1. Ref Counting I believe that ARC is a pipe dream for D, as we've discussed extensively here. But a ref counted object should work, and would be very attractive, much like C++'s shared_ptr. 2. Unique References unique_ptr is another big success for C++. 2.066 has already made big strides in inferring uniqueness of expressions, but it doesn't go so far as creating a Unique!T type. std.type.Unique needs to be fleshed out, or a different type created (`Owned`?). The current `Unique` accepts only pointers and classes, but should really accept anything, as with borrowing. Desirable features include: * explicit or implicit move-semantics * a way to remove uniqueness (e.g. after sending a value to a different thread, it no longer needs to be Unique) * compiler support for verifying that the value it's constructed from _is_ actually unique * deterministic destruction * allocator support (because of the previous point) * usable inside aggregates * applicable to any type; a move overwrites the rhs with the type's init value Borrowing can elegantly solve many of the problems with Unique and RC: * Unique and RefCounted should be implicitly borrowable (opBorrow?) * library routines pervasively take their inputs as `scope`; no need to provide different overloads for Unique, RefCounted, normal values, or even user-implemented wrappers => abstracts away the implementation details while retaining safety
Re: DIP65: Fixing Exception Handling Syntax
On 7/9/14, David Nadlinger via Digitalmars-d wrote: > On Wednesday, 9 July 2014 at 12:20:43 UTC, Andrej Mitrovic via > Digitalmars-d wrote: >> Give it a rest. If 'void foo(int, float)' is ok so should >> 'catch (E)' >> be. We can change the spec if we have to, it's easier than >> breaking code. > > Huh? Brian explicitly remarked earlier that Sorry, I misread what was being said.
Re: Bottom line re GC in D
On Wednesday, 9 July 2014 at 13:01:36 UTC, bearophile wrote: The huge amount of work done on the OracleVM GC that is not easy to match. D need for low-level code (currently user code can't tell the GC what are the current actual contents of a union, this includes Algebraic), D desire to interface efficiently to C code. I think it is a pity that there has been no real effort to experiment with restricting/extending semantics in a way that could lead to cache efficient GC collection. 1. annotate pointers that may point to GC memory (global dataflow or explict) 2. ensure that regular memory retain pointers to GC memory when it is live in C code 3. do global analysis of possible datastructures to minimize scanned fields/structs 4. improve stack traversal speed 5. improve ADTs with GC performance-enhancing features to reduce scanning 6. optional fat GC pointer implementations to get faster scanning But yeah, if one insists on having C semantics throughout, then there is no hope…
before D there was d
i recently sent this email to andrei. he encouraged me to post it in this forum. here it is: hi andrei a colleague recently pointed me to the wired article about you & your D computer language. thought you might be interested an earlier attempt to produce a new & better computer language that we called d (lower case). fear not, i am an engineer, not a lawyer, & do not sue people. my name is jim schmit. i am a retired engineer / professor / entrepreneur / international business man / corporate executive. I wrote my 1st program over 50 years ago. i worked for IBM as a systems engineer on the first OS on big iron. disillusioned with the consequences of complexity in computer design (i am a pathological minimalist), i dropped out to become a computer science professor & "do my own thing". i was extremely active at the birth of the microcomputer. in the mid 70's i created a programming system for small cheap control computers based on a stack architecture pseudo machine. it was tiny intended to fit entirely in a 2K byte eprom. the run time system consisted of a set of “base” functions that fit in less than 1/2 K bytes of memory. there was no interpreter, the code was threaded. the application fit in the other 1 1/2K. the functions used byte codes & used less than 1/3 the space of well written machine language and ran at 1/2 the speed of machine code. net results…3x the functionality in the same rom while far easier to write & debug code. i called it omega before i could commercialize my system, i was distracted. i was commissioned to design & build what became known as CompuTrac, the first microcomputer based technical analytic system for trading the commodities markets. it became an instant hit & we soon found ourselves at the forefront of real time trading systems. we developed initially for the apple II & later the PC. by the late 70’s we were searching for a new hardware platform & disappointed in the options available decided to “roll our own”. we revisited omega as the basis for a real time graphic workstation. a former customer, turned competitor, named his product omega, so we renamed the language d (after c). with 2 former student assistants, paul johnstone & ana maria roa, we started delta digital designs “strong designs & innovative coffee”. we introduced our delta computer with d software in late ’83. the software extended into the new windowed environment but remained small & quick. Our first product was called TradePlan. it was a real time vector spreadsheet with constantly changing graphic output. it could monitor 3 real time ticker feeds of exchange trading data, maintain a local data base of time series prices, feed 4 spreadsheets that were fully user programable to calculate technical indicators & create a trading system with alarms of opportunity & display all on constantly updating charts. the d machine run time system containing multitasking scheduler, real time i/o handlers, a complete graphic windowing capability ran in under 8K of code. The trade plan app code was under 24K. running on a 6809 processor, it was highly user responsive & could keep up with the workload. it became famous in it’s small world of finance. In 1985 both CompuTrac & Delta Digital Designs was bought by Dow Jones / Telerate. at dow, our products were renamed, extended & added to. we did another product called Matrix that was a user programmable financial market monitor / consolidator that proved very popular. In the late 80’s our products generated just under $1B revenue for DJ. Matrix used the 3rd iteration of the d language, rebuilt to be fully object oriented. I retired in 1992 but my team continued the work for dow & a series of other owners until 2003. if any of this is of any interest to you, please let me know. regards
Re: Opportunities for D
On Wednesday, 9 July 2014 at 07:10:09 UTC, Jacob Carlborg wrote: On 09/07/14 00:21, bearophile wrote: 9. Built-in tuples usable in all the most important situations (with a syntax that doesn't kill possible future improvements of the switch statement to perform basic pattern matching on structs that have an optional method named "unapply"). I think it would be possible to implement pattern matching in library code. Something like this: match!(value, (int t) => ifInt(), (char t) => ifChar(), () => noOtherMatch() ); Destructing a type could look something like this: match(value, (type!(Foo), int a, int b) => doSomething(), // match if value is of type Foo and extract it (int a, int b) => doSomething() // match anything that can be destructed to two ints ); The syntax is not so pretty but I think it would be possible. As far as I know, there's no reason we can't add pattern matching to switch or final switch or both. There's no ambiguity because right now it's not possible to switch on structs or classes. See Kenji's DIP32 for syntax for tuples that could be leveraged.
Re: before D there was d
On Wednesday, 9 July 2014 at 13:18:00 UTC, jim schmit wrote: i recently sent this email to andrei. he encouraged me to post it in this forum. here it is: hi andrei a colleague recently pointed me to the wired article about you & your D computer language. thought you might be interested an earlier attempt to produce a new & better computer language that we called d (lower case). fear not, i am an engineer, not a lawyer, & do not sue people. my name is jim schmit. i am a retired engineer / professor / entrepreneur / international business man / corporate executive. I wrote my 1st program over 50 years ago. i worked for IBM as a systems engineer on the first OS on big iron. disillusioned with the consequences of complexity in computer design (i am a pathological minimalist), i dropped out to become a computer science professor & "do my own thing". i was extremely active at the birth of the microcomputer. in the mid 70's i created a programming system for small cheap control computers based on a stack architecture pseudo machine. it was tiny intended to fit entirely in a 2K byte eprom. the run time system consisted of a set of “base” functions that fit in less than 1/2 K bytes of memory. there was no interpreter, the code was threaded. the application fit in the other 1 1/2K. the functions used byte codes & used less than 1/3 the space of well written machine language and ran at 1/2 the speed of machine code. net results…3x the functionality in the same rom while far easier to write & debug code. i called it omega before i could commercialize my system, i was distracted. i was commissioned to design & build what became known as CompuTrac, the first microcomputer based technical analytic system for trading the commodities markets. it became an instant hit & we soon found ourselves at the forefront of real time trading systems. we developed initially for the apple II & later the PC. by the late 70’s we were searching for a new hardware platform & disappointed in the options available decided to “roll our own”. we revisited omega as the basis for a real time graphic workstation. a former customer, turned competitor, named his product omega, so we renamed the language d (after c). with 2 former student assistants, paul johnstone & ana maria roa, we started delta digital designs “strong designs & innovative coffee”. we introduced our delta computer with d software in late ’83. the software extended into the new windowed environment but remained small & quick. Our first product was called TradePlan. it was a real time vector spreadsheet with constantly changing graphic output. it could monitor 3 real time ticker feeds of exchange trading data, maintain a local data base of time series prices, feed 4 spreadsheets that were fully user programable to calculate technical indicators & create a trading system with alarms of opportunity & display all on constantly updating charts. the d machine run time system containing multitasking scheduler, real time i/o handlers, a complete graphic windowing capability ran in under 8K of code. The trade plan app code was under 24K. running on a 6809 processor, it was highly user responsive & could keep up with the workload. it became famous in it’s small world of finance. In 1985 both CompuTrac & Delta Digital Designs was bought by Dow Jones / Telerate. at dow, our products were renamed, extended & added to. we did another product called Matrix that was a user programmable financial market monitor / consolidator that proved very popular. In the late 80’s our products generated just under $1B revenue for DJ. Matrix used the 3rd iteration of the d language, rebuilt to be fully object oriented. I retired in 1992 but my team continued the work for dow & a series of other owners until 2003. if any of this is of any interest to you, please let me know. regards Sounds quite impressive. Maybe it's a good omen for D.
Re: before D there was d
On 7/9/14, 6:17 AM, jim schmit wrote: i recently sent this email to andrei. he encouraged me to post it in this forum. here it is: hi andrei a colleague recently pointed me to the wired article about you & your D computer language. thought you might be interested an earlier attempt to produce a new & better computer language that we called d (lower case). fear not, i am an engineer, not a lawyer, & do not sue people. my name is jim schmit. i am a retired engineer / professor / entrepreneur / international business man / corporate executive. I wrote my 1st program over 50 years ago. i worked for IBM as a systems engineer on the first OS on big iron. disillusioned with the consequences of complexity in computer design (i am a pathological minimalist), i dropped out to become a computer science professor & "do my own thing". i was extremely active at the birth of the microcomputer. in the mid 70's i created a programming system for small cheap control computers based on a stack architecture pseudo machine. it was tiny intended to fit entirely in a 2K byte eprom. the run time system consisted of a set of “base” functions that fit in less than 1/2 K bytes of memory. there was no interpreter, the code was threaded. the application fit in the other 1 1/2K. the functions used byte codes & used less than 1/3 the space of well written machine language and ran at 1/2 the speed of machine code. net results…3x the functionality in the same rom while far easier to write & debug code. i called it omega before i could commercialize my system, i was distracted. i was commissioned to design & build what became known as CompuTrac, the first microcomputer based technical analytic system for trading the commodities markets. it became an instant hit & we soon found ourselves at the forefront of real time trading systems. we developed initially for the apple II & later the PC. by the late 70’s we were searching for a new hardware platform & disappointed in the options available decided to “roll our own”. we revisited omega as the basis for a real time graphic workstation. a former customer, turned competitor, named his product omega, so we renamed the language d (after c). with 2 former student assistants, paul johnstone & ana maria roa, we started delta digital designs “strong designs & innovative coffee”. we introduced our delta computer with d software in late ’83. the software extended into the new windowed environment but remained small & quick. Our first product was called TradePlan. it was a real time vector spreadsheet with constantly changing graphic output. it could monitor 3 real time ticker feeds of exchange trading data, maintain a local data base of time series prices, feed 4 spreadsheets that were fully user programable to calculate technical indicators & create a trading system with alarms of opportunity & display all on constantly updating charts. the d machine run time system containing multitasking scheduler, real time i/o handlers, a complete graphic windowing capability ran in under 8K of code. The trade plan app code was under 24K. running on a 6809 processor, it was highly user responsive & could keep up with the workload. it became famous in it’s small world of finance. In 1985 both CompuTrac & Delta Digital Designs was bought by Dow Jones / Telerate. at dow, our products were renamed, extended & added to. we did another product called Matrix that was a user programmable financial market monitor / consolidator that proved very popular. In the late 80’s our products generated just under $1B revenue for DJ. Matrix used the 3rd iteration of the d language, rebuilt to be fully object oriented. I retired in 1992 but my team continued the work for dow & a series of other owners until 2003. if any of this is of any interest to you, please let me know. regards Whew, Walter dodged a bullet there by capitalizing his "D" language! :) Seriously though, this is a fascinating glimpse at some interesting technology and history. Many thanks for taking the time to post this here.
Re: before D there was d
On Wednesday, 9 July 2014 at 13:18:00 UTC, jim schmit wrote: i recently sent this email to andrei. he encouraged me to post it in this forum. here it is: hi andrei a colleague recently pointed me to the wired article about you & your D computer language. thought you might be interested an earlier attempt to produce a new & better computer language that we called d (lower case). fear not, i am an engineer, not a lawyer, & do not sue people. my name is jim schmit. i am a retired engineer / professor / entrepreneur / international business man / corporate executive. I wrote my 1st program over 50 years ago. i worked for IBM as a systems engineer on the first OS on big iron. disillusioned with the consequences of complexity in computer design (i am a pathological minimalist), i dropped out to become a computer science professor & "do my own thing". i was extremely active at the birth of the microcomputer. in the mid 70's i created a programming system for small cheap control computers based on a stack architecture pseudo machine. it was tiny intended to fit entirely in a 2K byte eprom. the run time system consisted of a set of “base” functions that fit in less than 1/2 K bytes of memory. there was no interpreter, the code was threaded. the application fit in the other 1 1/2K. the functions used byte codes & used less than 1/3 the space of well written machine language and ran at 1/2 the speed of machine code. net results…3x the functionality in the same rom while far easier to write & debug code. i called it omega before i could commercialize my system, i was distracted. i was commissioned to design & build what became known as CompuTrac, the first microcomputer based technical analytic system for trading the commodities markets. it became an instant hit & we soon found ourselves at the forefront of real time trading systems. we developed initially for the apple II & later the PC. by the late 70’s we were searching for a new hardware platform & disappointed in the options available decided to “roll our own”. we revisited omega as the basis for a real time graphic workstation. a former customer, turned competitor, named his product omega, so we renamed the language d (after c). with 2 former student assistants, paul johnstone & ana maria roa, we started delta digital designs “strong designs & innovative coffee”. we introduced our delta computer with d software in late ’83. the software extended into the new windowed environment but remained small & quick. Our first product was called TradePlan. it was a real time vector spreadsheet with constantly changing graphic output. it could monitor 3 real time ticker feeds of exchange trading data, maintain a local data base of time series prices, feed 4 spreadsheets that were fully user programable to calculate technical indicators & create a trading system with alarms of opportunity & display all on constantly updating charts. the d machine run time system containing multitasking scheduler, real time i/o handlers, a complete graphic windowing capability ran in under 8K of code. The trade plan app code was under 24K. running on a 6809 processor, it was highly user responsive & could keep up with the workload. it became famous in it’s small world of finance. In 1985 both CompuTrac & Delta Digital Designs was bought by Dow Jones / Telerate. at dow, our products were renamed, extended & added to. we did another product called Matrix that was a user programmable financial market monitor / consolidator that proved very popular. In the late 80’s our products generated just under $1B revenue for DJ. Matrix used the 3rd iteration of the d language, rebuilt to be fully object oriented. I retired in 1992 but my team continued the work for dow & a series of other owners until 2003. if any of this is of any interest to you, please let me know. regards Cool story, bro.
Re: Opportunities for D
On 07/08/2014 11:22 PM, Walter Bright wrote: ... 3. 'ref' means 'borrowed', to use Rust's terminology We're almost there with this. This means better escape analysis, too. ... What makes you think that 'ref' is a good match for this functionality, and how are we almost there with this? 8. NotNull!T type For those that want a non-nullable reference type. This should be doable as a library type. No.
Re: @nogc and NSAutoReleasePool-style regions.
On Wednesday, 9 July 2014 at 12:07:27 UTC, Ola Fosheim Grøstad wrote: Another benefit with explicit GC pointers is that you could ban GC pointers to classes that provide destructors, sanitizing the constructor/destructor situation. This could also be done at the allocator level, though. An allocator presumably knows whether it's objects are garbage collected (hmm... maybe not necessarily?), and it can inspect types to find out whether they have destructors.
Re: Opportunities for D
On Wednesday, 9 July 2014 at 13:06:06 UTC, Marc Schütz wrote: std.type.Unique needs to be fleshed out, or a different type created (`Owned`?). There is an `Isolated` in vibe.d which is more tuned for usage with std.concurrency (its vibe.d fork to be specific)
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 01:35:49 UTC, Puming wrote: That commenter is probably a web developer that wants all batteries included. Yep. He mistook vibe.d for a complete web development framework, I suppose. It's quite common that people are put off because they expect too much or do not understand what the technology is really about. While we may not win this particular user back, it is important to clarify where s/he was mistaken, so that myths based on false assumptions are not propagated.
Re: @nogc and NSAutoReleasePool-style regions.
On Wednesday, 9 July 2014 at 14:36:37 UTC, Marc Schütz wrote: This could also be done at the allocator level, though. An allocator presumably knows whether it's objects are garbage collected (hmm... maybe not necessarily?), and it can inspect types to find out whether they have destructors. I think the advantage of using a region allocator would be to allocate and clean up quickly without any extra overhead beyond moving a pointer, but I guess new() could globally be restricted to classes that does not provide a destructor…
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote: Vibe.d is more like a base library for async I/O, networking and concurrency, a full stack WEB framework should be built on top of it which focus on application development and ease of use for newcomers. Sonke has said that too. Vibe.d should focus on performance, networking, and other lowerlevel stuff that D should be really good at. Sonke is already too busy doing his gorgeous work on vibe.d and dub. I think that is what the guy on reddit was complaining, he thought vibe.d should contain everything from a web framework, but didn't find them, thus getting the impression that vibe.d was not complete. Actually vibe.d is just an edge of a triangle in web frameworks. We are lacking the other two pieces. Huh. I guess it depends what your goal is. For the kind of work I do, vibe.d is in the right ballpark. The services I create basically respond to AJAX calls (JSON-RPC is the best, though REST is okay too) and do other back-end work. I've never had a need to do any HTML handling or anything like that. I might take issue with the specifics of how some of the APIs are designed, but not with the feature set.
Re: critique of vibe.d
Am 09.07.2014 03:54, schrieb luminousone: There is lots of missing little bits here and their, password hashing functions that use crypt_(C) formated hashes. I was hoping for dauth [1] to fill that gap. It doesn't use the same format, but one with the same goal. I didn't actually try it out yet, though. There are diet/jade template bugs still, specific major problem being that use of single quotes inside of double quotes when i need to pass strings to js functions inside of js events such as onclick inside a html tag, seems to be broken. Do you have a concrete example where this goes wrong? I've tested both, nesting ' inside " and vice versa. Both seemed to work fine for onLoad=...>. There is not common database interface for sql databases(forgivable actually), but many of the specific database libraries are messy(ddb for example) and they are not any where near api "stable". Support for mongo is... cute?!, don't get me wrong it has a place, for most apps it would be fine, it is however unusable for the apps i am involved in. Yeah, I kind of like it for its flexibility, but it's definitely not the right choice for million user web services. I'm currently looking at NouDB as another potential SQL based target. [1]: http://code.dlang.org/packages/dauth
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: Also, in playframework, vert.x and nodejs, they all have a plugin/module system, that people could easily compose plugins to make a website. (I call it plugin because that is what play used to call it, now they all call it a module but that name will easily conflict with D's sourcecode modules). This is a critical mechanism that actually allured developers to contribute to the eco-system. On a related note, one thing vibe.d is really missing from my perspective is a good way to handle unstable processes and perform seamless code upgrades (this is where Erlang really shines IMO). It would be cool if there were a process monitor at least. The system I work with does some fancy stuff with UDS, but that probably isn't necessary. I'll admit that the ball is probably kind of in my court here, since IPC would be a handy way of communicating process health, but something simpler using pipes or whatever would work as well.
[OT] Re: Redesign of dlang.org
On 09/07/2014 12:36 PM, Chris wrote: On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via Digitalmars-d And everyone should drive on the left. Driving on the left goes back to the times when coaches (carriages) were still in use. This was to avoid that drivers would accidentally hit each other with their whips when a coach would come from the opposite direction. No joke. As regards cars, driving on the left is highly unintuitive for most people as the majority of drivers are right-handed. There is no ergonomic or technical reason why cars should drive on the left. In most parts of the world driving on the right was adopted from early on as it is more intuitive (for most people). Driving on the left actually originates from jousting. On a tilting yard each combatant rides on the right side and aims their lance across their body at the opponent in the lane on the left. When knights passed each other out on the roads, the would do so on the left side so show that they were not hostile. The whole of Europe took up this practice, and used to always ride, drive carts and march as a body of men on the left. Then a chap called Napoleon came along and used a guerilla tactic to trick his enemy by marching on the right so that his troops looked like they were travelling in the opposite direction. Eventually driving on the wrong side became the norm for all the regions of Europe that Napoleon conquered, and it spread as a matter of practicality to adjacent regions over time. Napoleon was defeated by the English because this trick does not work at sea. The UK still drives on the correct side because there is no problem with having to swap sides when crossing land borders. It is also an act that commemorates that historic victory. Or at least that is what I learned in school ^^ A...
Re: Opportunities for D
On 08/07/2014 23:40, Remo wrote: What about the already present std.typecons.Unique? Unfortunately there are a lot of /+Doesn't work yet+/ comments in std.typecons.Unique code. I think it was written a long time ago. I think much of those parts will work now. I'm slowly going through them and will make more PRs, here's the first one, to disable postblit: https://github.com/D-Programming-Language/phobos/pull/2308
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 09:48:32 UTC, Dicebot wrote: On Wednesday, 9 July 2014 at 09:47:21 UTC, Dicebot wrote: On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: "has anyone ever tied a real webservice to vibe.d?" Yes and see no problems with it. Looks like author has very specific expectations of "webservice" concept and can't do a thing with 100% .. coverage of all utilities in the library. Sad he does not provide some sample of missing bits. Most likely he has expected vibe.d to be exclusively web framework while it is generic networking / async framework. Yeah, connection-based protocols are where UDS really shines for supporting seamless upgrades. Transaction-based protocols like HTTP are much easier to deal with in this respect.
Re: [OT] Re: Redesign of dlang.org
On Wednesday, 9 July 2014 at 15:34:03 UTC, Alix Pexton wrote: On 09/07/2014 12:36 PM, Chris wrote: On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via Digitalmars-d And everyone should drive on the left. Driving on the left goes back to the times when coaches (carriages) were still in use. This was to avoid that drivers would accidentally hit each other with their whips when a coach would come from the opposite direction. No joke. As regards cars, driving on the left is highly unintuitive for most people as the majority of drivers are right-handed. There is no ergonomic or technical reason why cars should drive on the left. In most parts of the world driving on the right was adopted from early on as it is more intuitive (for most people). Driving on the left actually originates from jousting. On a tilting yard each combatant rides on the right side and aims their lance across their body at the opponent in the lane on the left. When knights passed each other out on the roads, the would do so on the left side so show that they were not hostile. The whole of Europe took up this practice, and used to always ride, drive carts and march as a body of men on the left. Then a chap called Napoleon came along and used a guerilla tactic to trick his enemy by marching on the right so that his troops looked like they were travelling in the opposite direction. Eventually driving on the wrong side became the norm for all the regions of Europe that Napoleon conquered, and it spread as a matter of practicality to adjacent regions over time. Napoleon was defeated by the English because this trick does not work at sea. The UK still drives on the correct side because there is no problem with having to swap sides when crossing land borders. It is also an act that commemorates that historic victory. Or at least that is what I learned in school ^^ A... This sounds just like Imperial education. Very interesting how it equates Imperial practices with the "right" thing and the (continental) arch enemy with the "wrong" thing. By the way, there was a reason why combatant riders would ride on the right side on a tilting yard: they were right-handed. Just as it makes more sense to switch gears with the right hand and not with the (in most cases) weaker left hand.
Re: before D there was d
Interesting story. Thanks for posting it. I remember Telerate! That was the reason we had a PC in our house in the 80s. If it weren't for that, I may not have ended up a programmer.
Re: Opportunities for D
On Wed, Jul 09, 2014 at 12:47:30AM -0700, Walter Bright via Digitalmars-d wrote: > On 7/8/2014 10:00 PM, H. S. Teoh via Digitalmars-d wrote: > >On Tue, Jul 08, 2014 at 07:42:50PM -0700, Walter Bright via Digitalmars-d > >wrote: > >>On 7/8/2014 3:37 PM, bearophile wrote: [...] > >>>Is "scope" still left for future usage, or used for a different > >>>purpose, or deprecated? > >> > >>That would have to be addressed as part of this. > > > >Does that mean that finally 'scope' will work as advertised? I've > >been waiting for that for a long time. > > Help is welcome working on a design. I would, except that I'm unsure of exactly what is needed in said design. Are we just trying to nail down the exact semantics of 'scope'? Or are we looking at implementational issues (possible compiler performance hits)? Or both? Or something else altogether? Do we need to account for (what little exists of) the current implementation? Speaking of which, what *is* the current extent of the implementation of 'scope'? I assume it isn't just a no-op, since I see it applied to delegate parameters every now and then? T -- What's a "hot crossed bun"? An angry rabbit.
Re: critique of vibe.d
Am 09.07.2014 17:17, schrieb Sean Kelly: I might take issue with the specifics of how some of the APIs are designed, but not with the feature set. Please be vocal about such design issues :) I think most parts are in a pretty good shape, but there is of course almost always room for improvement (the Json/Bson types come to mind).
Re: critique of vibe.d
Am 09.07.2014 17:26, schrieb Sean Kelly: On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: Also, in playframework, vert.x and nodejs, they all have a plugin/module system, that people could easily compose plugins to make a website. (I call it plugin because that is what play used to call it, now they all call it a module but that name will easily conflict with D's sourcecode modules). This is a critical mechanism that actually allured developers to contribute to the eco-system. On a related note, one thing vibe.d is really missing from my perspective is a good way to handle unstable processes and perform seamless code upgrades (this is where Erlang really shines IMO). It would be cool if there were a process monitor at least. The system I work with does some fancy stuff with UDS, but that probably isn't necessary. I'll admit that the ball is probably kind of in my court here, since IPC would be a handy way of communicating process health, but something simpler using pipes or whatever would work as well. This is what vibedist [1] was/is intended for, but unfortunately I never found the time to really finish it so far. [1]: https://github.com/rejectedsoftware/vibedist
Re: Opportunities for D
Dicebot: I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one. This article talks about switching to NotNull on default in real (small) Java projects (you have to add a @NonNullByDefault at package level to change the default): http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html Bye, bearophile
Re: critique of vibe.d
Am Wed, 09 Jul 2014 18:16:49 +0200 schrieb Sönke Ludwig : > Am 09.07.2014 17:26, schrieb Sean Kelly: > > On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: > >> Also, in playframework, vert.x and nodejs, they all have a > >> plugin/module system, that people could easily compose plugins to > >> make a website. (I call it plugin because that is what play used > >> to call it, now they all call it a module but that name will > >> easily conflict with D's sourcecode modules). This is a critical > >> mechanism that actually allured developers to contribute to the > >> eco-system. > > > > On a related note, one thing vibe.d is really missing from my > > perspective is a good way to handle unstable processes and perform > > seamless code upgrades (this is where Erlang really shines IMO). It > > would be cool if there were a process monitor at least. The system > > I work with does some fancy stuff with UDS, but that probably isn't > > necessary. I'll admit that the ball is probably kind of in my court > > here, since IPC would be a handy way of communicating process > > health, but something simpler using pipes or whatever would work as > > well. > > This is what vibedist [1] was/is intended for, but unfortunately I > never found the time to really finish it so far. > > [1]: https://github.com/rejectedsoftware/vibedist Completely off-topic, but: Have you considered making vibe http-backend independent? So that it could provide a fcgi interface or be included in an nginx plugin? Also as D plugins now seem to work more or less have you considered loading webpages dynamically from .so files? Then we could invent some file extension - like .dpage - and have one vibe fcgi process handle all .dpage files. The process then simply loads the .dpage shared library, calls some function (extern(C) IWebSite vibe_get_site()) etc. Basically the way asp.net works, IIRC.
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote: Completely off-topic, but: Have you considered making vibe http-backend independent? So that it could provide a fcgi interface or be included in an nginx plugin? What is the benefit as opposed to using proxy_pass at nginx? fcgi will be slower than built-in vibe.d HTTP server.
Re: Opportunities for D
On Wednesday, 9 July 2014 at 17:01:02 UTC, bearophile wrote: Dicebot: I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one. This article talks about switching to NotNull on default in real (small) Java projects (you have to add a @NonNullByDefault at package level to change the default): http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html Bye, bearophile Yes and this is exactly what we can't do in D. So what is the point of discussing library NonNull then?
Re: Opportunities for D
Dicebot: Yes and this is exactly what we can't do in D. I don't understand, if they can do that with Java, why not D? Bye, bearophile
Re: Opportunities for D
On Wednesday, 9 July 2014 at 18:09:58 UTC, bearophile wrote: Dicebot: Yes and this is exactly what we can't do in D. I don't understand, if they can do that with Java, why not D? Bye, bearophile Java bytecode reflection makes possible to find all reference types in an attributed package and replace them to non-nullables. D compile-time reflection is currently limited to declaration (with a very 1few exceptions) - I am not aware of any ways to do it other than hot-patching generated machine code (not really an option). One thing we can do is to validate that there are no nullable references in public signatures but this is something more suitable for static analysis rule anyway.
Re: critique of vibe.d
On 7/9/2014 10:49 AM, Chris wrote: On Wednesday, 9 July 2014 at 01:35:49 UTC, Puming wrote: That commenter is probably a web developer that wants all batteries included. Yep. He mistook vibe.d for a complete web development framework, I suppose. It's quite common that people are put off because they expect too much or do not understand what the technology is really about. While we may not win this particular user back, it is important to clarify where s/he was mistaken, so that myths based on false assumptions are not propagated. Can't it be used as a complete web framework? I mean, assuming you're happy with the built-in templating and DB options? Or is everyone using "web framework" here to really mean "CMS"?
Re: critique of vibe.d
Am 09.07.2014 19:03, schrieb Johannes Pfau: Am Wed, 09 Jul 2014 18:16:49 +0200 schrieb Sönke Ludwig : Am 09.07.2014 17:26, schrieb Sean Kelly: On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: Also, in playframework, vert.x and nodejs, they all have a plugin/module system, that people could easily compose plugins to make a website. (I call it plugin because that is what play used to call it, now they all call it a module but that name will easily conflict with D's sourcecode modules). This is a critical mechanism that actually allured developers to contribute to the eco-system. On a related note, one thing vibe.d is really missing from my perspective is a good way to handle unstable processes and perform seamless code upgrades (this is where Erlang really shines IMO). It would be cool if there were a process monitor at least. The system I work with does some fancy stuff with UDS, but that probably isn't necessary. I'll admit that the ball is probably kind of in my court here, since IPC would be a handy way of communicating process health, but something simpler using pipes or whatever would work as well. This is what vibedist [1] was/is intended for, but unfortunately I never found the time to really finish it so far. [1]: https://github.com/rejectedsoftware/vibedist Completely off-topic, but: Have you considered making vibe http-backend independent? So that it could provide a fcgi interface or be included in an nginx plugin? That could be done pretty easily by providing an alternative to listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)). It could use the HTTPServerRequest and HTTPServerResponse classes more or less just like the HTTP server does. Also as D plugins now seem to work more or less have you considered loading webpages dynamically from .so files? Then we could invent some file extension - like .dpage - and have one vibe fcgi process handle all .dpage files. The process then simply loads the .dpage shared library, calls some function (extern(C) IWebSite vibe_get_site()) etc. Basically the way asp.net works, IIRC. That would be pretty much what Rikki Cattermole is planning to do with Cmsed [1]. For vibe.d it would be a bit too much at this time. There is still a lot that I would like to get done on the lower levels of the library, so that the basis is really solid sooner rather than later. The highest level features planned for now are the descriptive REST and web interface modules. However, there is a plan for using dynamic libraries to support seamless live editing/reloading of individual Diet templates [2]. [1]: http://code.dlang.org/packages/cmsed [2]: https://github.com/rejectedsoftware/vibe.d/issues/676
Re: critique of vibe.d
From my usage of vibe.d thus far, I've found that it has a lot of things I want if I were to use it for building sites like the sites I build at work. vibe.d can offer excellent performance and scalability, and those are great building blocks to have for building a great web framework. I think what's missing from vibe.d lies in D code yet to be written which is required to get a decent level of productivity. I am primarily a Django developer these days, and Django has some great features which boost my productivity massively. I'd want to see the same features, only written in a way more appropriate for D, in vibe.d. Here's a short list. * An ORM, which absolutely must have a way to build queries a piece at a time without writing any SQL, like Django. * A framework for generating all of the SQL required for database migrations like South or the built in migrations in Django 1.7, so you can quickly change any model. * An API for creating form handlers, especially for creating instances of models in the ORM through forms. (Django Form and ModelForm) * An HTML template system which doesn't eat memory at compile time and where changes can be made while the development server is running. Those are the important "must have" points. Because of these features in Django, I can create a new feature for a website in the space of a couple of days, wildly restructure databases for optimisations etc. There are a few other tools I use in Django that are very nice to have. * Django's automated testing framework lets you test pages with session data and email output, so I have tests for complex things like checkouts which are very easy to write. I pair it with a Jenkins module so I can use Jenkins locally for CI. * The django-debug-toolbar module saves a ton of time when optimising queries. I use it for loading pages and looking at all of the queries run in a timeline with all of the EXPLAIN output right there. As a result I have massively improved query times at my job. * The Django pipeline module provides mechanisms for generating JS and CSS. I now have SCSS which regenerates CSS automatically during development without needing a filesystem monitor like Compass, and I have cut load times on a couple of pages by a second each by merging JavaScript together. (Even without minification, which it supports, which I haven't gotten to yet.) So there's my wishlist. I see it as a TODO list of things I or someone else should write. I'd be willing to contribute to a few of those points whenever I have time.
Re: before D there was d
On 7/9/14, 7:25 AM, David Gileadi wrote: Seriously though, this is a fascinating glimpse at some interesting technology and history. Many thanks for taking the time to post this here. Seconded. Thanks Jim! -- Andrei
Re: critique of vibe.d
On 7/9/2014 11:21 AM, Sönke Ludwig wrote:
Am 09.07.2014 03:54, schrieb luminousone:
There is lots of missing little bits here and their, password hashing
functions that use crypt_(C) formated hashes.
I was hoping for dauth [1] to fill that gap. It doesn't use the same
format, but one with the same goal. I didn't actually try it out yet,
though.
I admit I'm unfamiliar with this "crypt_(C) formated hashes", I'll look
it up and try to support it. Anyone happen to have a link handy?
Also, if anyone has ANY issues/concerns/questions/anything about DAuth,
PLEASE speak up or submit an issue at github. I want DAuth to work well
for everyone :)
Speaking of DAuth future direction, I may as well mention this and open
it for comment:
My plan ATM is to expand DAuth's scope a little, split it into about
three main components (at different levels of abstraction) and rename to
something less likely to be mistaken for an OAuth lib (DAuth is
unrelated to OAuth).
I'm thinking of something like this:
"InstaUser Core": Basically what DAuth is now. Provides the two main
primitives "Convert plaintext password to a salted hash" and "Validate
plaintext password against a salted hash". Plus all the optional
lower-level stuff like dealing with salts/hashes/etc directly, selecting
hash algos directly, customized salted-hash formats, one-use tokens, etc.
"InstaUser Store": I've already started work on this locally. Basically
a simple (compile-time, static linked) plugin architecture that provides
basic user-management primitives (create user, change user's password,
validate a password against a user, delete user, etc) with pluggable
storage backends ("Stores") like MySQL. Various storage backends would
be included.
"InstaUser Web": This would leverage vibe.d to provide an out-of-the-box
working (and customizable) web-based register/login system. I expect
that some applications may (or might not) outgrow this, but I think it
would be fantastic for getting a login-based site off the ground and
up-and-running. Or even just putting files (like webalyzer stats) behind
a login that isn't "HTTP auth". I've written/maintained sooo many web
login systems over the years I've gotten sick of reimplementing sooo
many of the same things every time and backporting all newer
improvements (Which is really the whole original reason I started DAuth
in the first place).
An application can use *just* Core and omit the Store/Web stuff
entirely. Or they can use it at the Store level. Or at the Web level. Or
make direct use of all the levels.
Further in the future, "InstaUser" could possibly grow support for the
"login in via Facebook/Gmail/OpenID/whatever" that seems to be popular
now, or whatever other authentication systems may be useful.
"Destroy!"
[1]: http://code.dlang.org/packages/dauth
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:
Am 09.07.2014 03:54, schrieb luminousone:
There is lots of missing little bits here and their, password
hashing
functions that use crypt_(C) formated hashes.
I was hoping for dauth [1] to fill that gap. It doesn't use the
same format, but one with the same goal. I didn't actually try
it out yet, though.
There are diet/jade template bugs still, specific major
problem being
that use of single quotes inside of double quotes when i need
to pass
strings to js functions inside of js events such as onclick
inside a
html tag, seems to be broken.
Do you have a concrete example where this goes wrong? I've
tested both, nesting ' inside " and vice versa. Both seemed to
work fine for .
There is not common database interface for sql
databases(forgivable
actually), but many of the specific database libraries are
messy(ddb for
example) and they are not any where near api "stable".
Support for mongo is... cute?!, don't get me wrong it has a
place, for
most apps it would be fine, it is however unusable for the
apps i am
involved in.
Yeah, I kind of like it for its flexibility, but it's
definitely not the right choice for million user web services.
I'm currently looking at NouDB as another potential SQL based
target.
[1]: http://code.dlang.org/packages/dauth
hopefully, these posts are simply read as text, if not I can
figure out something else.
a.menu_item(href='#', onclick='load("invoice");') New Invoice
a.menu_item(href='#', onclick="load('invoice');") New Invoice
will always generate the following output,
New
Invoice
New Invoice
Cool Stuff for D that we keep Secret
Vladimir's talk on Dustmite is now up on Reddit. We ship Dustmite as part of the dmd distribution. But it's a secret. Just try to find out anything or any mention of Dustmite on dlang.org. The idea "Build It, and They Will Come" is a stupid hollywood myth. We cannot go on with creating fantastic, revolutionary tools and then keep them a secret. Dustmite is just one example of this, but it's on top of my head because I went looking for a link to it to go with the Reddit pointer to the video. It fits in quite nicely with my previous antics at discovering there were no links to gdc or ldc instructions, and no mention anywhere that to get gdc on Ubuntu, one only needs to type: sudo apt-get install gdc All you guys building stuff - it's all WASTED EFFORT if you don't make it findable by users. /rant
Re: critique of vibe.d
On 7/9/2014 3:05 PM, w0rp wrote: * An API for creating form handlers, especially for creating instances of models in the ORM through forms. (Django Form and ModelForm) What I've started doing, and absolutely love so far, is to write my forms purely in the HTML template (with a little bit a custom tags/attributes), then use Adam's HTML DOM to read that HTML form and generate all the backend form-handing *from* the HTML form, including all the appropriate per-field "validation failed". I'm finding this works a lot better than defining forms in the backend code and then trying to generate the HTML I want from that. * An HTML template system which doesn't eat memory at compile time and where changes can be made while the development server is running. Mustache-D: https://github.com/repeatedly/mustache-d Unfortunately it *only* supports runtime processing right now, but it's a fairly nice little templating system. The claims of being "logicless" are total BS, but a *truly* logicless system would be useless anyway.
Re: before D there was d
On 7/9/2014 7:25 AM, David Gileadi wrote: Whew, Walter dodged a bullet there by capitalizing his "D" language! :) This is the first I've heard of that product, it is fun hearing about it!
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 15:17:03 UTC, Sean Kelly wrote: Huh. I guess it depends what your goal is. For the kind of work I do, vibe.d is in the right ballpark. The services I create basically respond to AJAX calls (JSON-RPC is the best, though REST is okay too) and do other back-end work. The JSON stuff may be nice, but I would prefer some more rigor (I am writing mostly c++ desktop apps, for the server side I am still open). My 'vision' is a stack with Vibe, Thrift and PostgreSQL. Everything plugged inside the vibe's async io and its own task/fiber concurrency. I think a good direction would be to dispatch the in-proc-service method calls with vibe's concurrency/task message passing. This would bring 'async' by default (a service would yield as is waits for database or other services) and it would guarantee that the requests are processed serially by a service (no concurrency or reentrancy problems). Bonus points if the services can be easily moved from in-process to other machines.
Re: critique of vibe.d
Am 09.07.2014 21:19, schrieb Nick Sabalausky: "InstaUser Web": This would leverage vibe.d to provide an out-of-the-box working (and customizable) web-based register/login system. I expect that some applications may (or might not) outgrow this, but I think it would be fantastic for getting a login-based site off the ground and up-and-running. Or even just putting files (like webalyzer stats) behind a login that isn't "HTTP auth". I've written/maintained sooo many web login systems over the years I've gotten sick of reimplementing sooo many of the same things every time and backporting all newer improvements (Which is really the whole original reason I started DAuth in the first place). An application can use *just* Core and omit the Store/Web stuff entirely. Or they can use it at the Store level. Or at the Web level. Or make direct use of all the levels. Further in the future, "InstaUser" could possibly grow support for the "login in via Facebook/Gmail/OpenID/whatever" that seems to be popular now, or whatever other authentication systems may be useful. This was also exactly my idea with the "userman" [1] and "user-auth" [2] packages, although I didn't get very far with the "user-auth" part, yet. Maybe we can join forces there. (Please excuse the awfully creative names, I created a lot of packages at once at the time ;) [1]: https://github.com/rejectedsoftware/userman [2]: https://github.com/rejectedsoftware/user-auth
Go-style schedulers for C++ we should look at
A coworker collected a good reading list: http://www.cs.kent.ac.uk/projects/ofa/c++csp/ http://maciekgajewskiprogramming.blogspot.nl/ http://morsmachine.dk/go-scheduler http://www1.cs.columbia.edu/~aho/cs6998/reports/12-12-11_DeshpandeSponslerWeiss_GO.pdf https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/edit http://golang.org/src/pkg/runtime/proc.c Who would like to take up such a project? Andrei
Re: critique of vibe.d
On 2014-07-08 9:32 PM, Puming wrote: Also, in playframework, vert.x and nodejs, they all have a plugin/module system, that people could easily compose plugins to make a website. (I call it plugin because that is what play used to call it, now they all call it a module but that name will easily conflict with D's sourcecode modules). This is a critical mechanism that actually allured developers to contribute to the eco-system. This is phenomenal work from my perspective because it needs to be original to justify the move. However, I was too tempted by the functional nature of D and my imagination motivated me to build the technicalities for some huge infrastructures behind a next-gen CMS. I have a chart up at https://github.com/globecsys/spee.d about what's involved with it, on my schedule for all components there should be at least 300 hours of work left. I'm aiming for a standalone executable library-oriented framework, which would give a cross-platform wordpress-like CMS installation that technically should scale _infinitely_. There's a few issues with infinite scalability behind NAT firewall nodes, like - the solution would be a websocket communication with (http://wamp.ws/) a more advanced protocol is elementary. - a cache database (I have a local redis-like one up called cache.d) needs to "talk" to hash-distributed master DBs with replication - this cache database would be modified to take advantage of the GC to avoid making additional copies on a server (store some void* in memory, serialized data on the filesystem). - library support would be with the same interface as wordpress: add_filter, add_action, etc - but a focus on Backbone.marionette for front-end js-based structuring with REST/json backend data provider - a custom D-based TLS library would help maximize code inlining in the streams and minimize points of attack - a DER and length-value serialization library would help minimize boilerplate I'm still brainstorming on the geolocation and domain-clustering of master nodes and load balancing. I'm finishing up work on a completely generic ASN.1 compiler with support for Information Objects that generates D structures for TLS: https://github.com/globecsys/asn1.d This is necessary because there's over 7000 lines of structure definitions involved: https://github.com/globecsys/asn1.d/blob/master/tls.asn1 Anyways, enough typing about this for the moment, I'm not looking for help :)
Re: Opportunities for D
On 7/9/2014 3:20 AM, Dicebot wrote:
Last time we talked about it during dconf you have mentioned doing necessary
escape analysis for borrowing semantics is too complicated to consider :) Ad if
you don't mean transitive, you shouldn't refer to Rust borrowing terminology as
any ownership type is normally transitive there.
Yes, I mean transitive, and understand what that implies.
5. Precise and Concurrent GC
There's been a lot of work on this, but I don't know where we stand on it.
I have started work on porting the CDGC to D2, have compilable version (that was
easy thanks to earlier Sean work) but updating implementation to match new
druntime and pass tests will take quite some time.
Is CDGC's Luca's earlier work on concurrent GC?
7. "D-Routines" - goroutines for D
Goroutines are the killer feature of Go for a number of sensible people. We
pretty much have this already with fibers, but what is lacking is a scheduler,
which will take some effort, and a "Channel" type, which should be easy.
I'd state it differently: "Marketing fuss about goroutines is the killer feature
of Go" :) It does not have any fundamental advantage over existing actor model
and I doubt it will matter _that_ much.
Much of the froth about Go is dismissed by serious developers, but they nailed
the goroutine thing. It's Go's killer feature.
8. NotNull!T type
For those that want a non-nullable reference type. This should be doable as a
library type.
I don't know where it comes from but non-nullable reference type has ZERO value
if it is not the default one.
Making it the default is impossible for D. However,
class _C { ... }
alias NotNull!_C C;
is entirely practical. It's not unlike the common C practice:
typedef struct S { ... } S;
to bring S out of the tag name space.
Re: critique of vibe.d
Am 09.07.2014 21:21, schrieb luminousone:
On Wednesday, 9 July 2014 at 15:21:40 UTC, Sönke Ludwig wrote:
Am 09.07.2014 03:54, schrieb luminousone:
There is lots of missing little bits here and their, password hashing
functions that use crypt_(C) formated hashes.
I was hoping for dauth [1] to fill that gap. It doesn't use the same
format, but one with the same goal. I didn't actually try it out yet,
though.
There are diet/jade template bugs still, specific major problem being
that use of single quotes inside of double quotes when i need to pass
strings to js functions inside of js events such as onclick inside a
html tag, seems to be broken.
Do you have a concrete example where this goes wrong? I've tested
both, nesting ' inside " and vice versa. Both seemed to work fine for
.
There is not common database interface for sql databases(forgivable
actually), but many of the specific database libraries are messy(ddb for
example) and they are not any where near api "stable".
Support for mongo is... cute?!, don't get me wrong it has a place, for
most apps it would be fine, it is however unusable for the apps i am
involved in.
Yeah, I kind of like it for its flexibility, but it's definitely not
the right choice for million user web services. I'm currently looking
at NouDB as another potential SQL based target.
[1]: http://code.dlang.org/packages/dauth
hopefully, these posts are simply read as text, if not I can
figure out something else.
a.menu_item(href='#', onclick='load("invoice");') New Invoice
a.menu_item(href='#', onclick="load('invoice');") New Invoice
will always generate the following output,
New
Invoice
New Invoice
That's right, but as far as I understand, it *should* work like that,
because HTML character entity replacement should happen before parsing
the JavaScript code, even if it's a little more verbose than it should be.
Re: Opportunities for D
Walter Bright: Making it the default is impossible for D. Is it impossible any strategy analogous to the Java one, as visible in the link I've shown earlier in this thread? http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html Bye, bearophile
Re: Opportunities for D
On 7/9/2014 7:37 AM, Timon Gehr wrote: On 07/08/2014 11:22 PM, Walter Bright wrote: 3. 'ref' means 'borrowed', to use Rust's terminology We're almost there with this. This means better escape analysis, too. What makes you think that 'ref' is a good match for this functionality, and how are we almost there with this? 'ref' is already used conventionally in such a manner as implying it is borrowed. 'ref' pointers cannot be stored, and one cannot take the address of a ref'd variable in @safe code. 8. NotNull!T type For those that want a non-nullable reference type. This should be doable as a library type. No. Rationale?
@nogc required on C API callbacks?
https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/signal.d When @nogc was added to the top of that file, the type of sigfn_t changed from "void function(int) extern (C) @system nothrow" to "void function(int) extern (C) @system nothrow @nogc". This breaks some code such as the ae library used by Digger. (The @nogc annotation is now required on signal handlers). The argument for requiring @nogc on C library callbacks makes sense to me, so I'd like to know if this was intentional.
Re: Opportunities for D
On 7/9/2014 9:08 AM, H. S. Teoh via Digitalmars-d wrote: I would, except that I'm unsure of exactly what is needed in said design. I'm unsure as well. That's why design work is needed! Are we just trying to nail down the exact semantics of 'scope'? Or are we looking at implementational issues (possible compiler performance hits)? Or both? Or something else altogether? Do we need to account for (what little exists of) the current implementation? Speaking of which, what *is* the current extent of the implementation of 'scope'? I assume it isn't just a no-op, since I see it applied to delegate parameters every now and then? Yes, yes, yes, ... these are questions that all need investigation and answering.
Re: @nogc required on C API callbacks?
On 7/9/2014 12:54 PM, Brian Schott wrote: https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/signal.d When @nogc was added to the top of that file, the type of sigfn_t changed from "void function(int) extern (C) @system nothrow" to "void function(int) extern (C) @system nothrow @nogc". This breaks some code such as the ae library used by Digger. (The @nogc annotation is now required on signal handlers). The argument for requiring @nogc on C library callbacks makes sense to me, so I'd like to know if this was intentional. I agree that callbacks shouldn't throw. The problem is existing code uses callbacks that aren't annotated with 'nothrow', and we don't like breaking all their code.
Re: Opportunities for D
On 7/9/2014 12:54 PM, bearophile wrote: Walter Bright: Making it the default is impossible for D. Is it impossible any strategy analogous to the Java one, as visible in the link I've shown earlier in this thread? http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html That's essentially just adding an attribute, like: @nogc: to the beginning of a module. It's not making it the default.
Re: Opportunities for D
On 7/9/2014 8:38 AM, Nick Treleaven wrote: On 08/07/2014 23:40, Remo wrote: What about the already present std.typecons.Unique? Unfortunately there are a lot of /+Doesn't work yet+/ comments in std.typecons.Unique code. I think it was written a long time ago. I think much of those parts will work now. I'm slowly going through them and will make more PRs, here's the first one, to disable postblit: https://github.com/D-Programming-Language/phobos/pull/2308 More things that need to happen with Unique: Unique!T u = ...; immutable p = u;// unique references can be implicitly cast to immutable Unique!(int*) u = new int; // must work int* p = new int; Unique!(int*) u = p; // must fail
Re: before D there was d
On Wed, Jul 09, 2014 at 12:38:42PM -0700, Walter Bright via Digitalmars-d wrote: > On 7/9/2014 7:25 AM, David Gileadi wrote: > >Whew, Walter dodged a bullet there by capitalizing his "D" language! :) > > This is the first I've heard of that product, it is fun hearing about it! On that note, the "Mars programming language" is also already taken (as I've pointed out elsewhere recently): http://ww2.cs.mu.oz.au/~mgiuca/mars/ The frequency of name collisions makes me think that the programming language market is far too saturated, in spite of only a handful of languages actually being generally viable. T -- Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. -- Gene Wirchenko
Re: @nogc required on C API callbacks?
On Wednesday, 9 July 2014 at 19:59:21 UTC, Walter Bright wrote: I agree that callbacks shouldn't throw. The problem is existing code uses callbacks that aren't annotated with 'nothrow', and we don't like breaking all their code. I was talking about @nogc (added in April, so before the 2.066 beta and after the 2.065 release). nothrow has been there since 2012 according to git blame, so nothrow is not what's causing the signal handling code to not compile.
Re: Opportunities for D
On Wed, Jul 09, 2014 at 12:51:40PM -0700, Walter Bright via Digitalmars-d wrote: > On 7/9/2014 9:08 AM, H. S. Teoh via Digitalmars-d wrote: > >I would, except that I'm unsure of exactly what is needed in said > >design. > > I'm unsure as well. That's why design work is needed! > > >Are we just trying to nail down the exact semantics of 'scope'? > >Or are we looking at implementational issues (possible compiler > >performance hits)? Or both? Or something else altogether? Do we need to > >account for (what little exists of) the current implementation? Speaking > >of which, what *is* the current extent of the implementation of 'scope'? > >I assume it isn't just a no-op, since I see it applied to delegate > >parameters every now and then? > > Yes, yes, yes, ... these are questions that all need investigation and > answering. Surely the last question doesn't need *investigation* per se?? Or do we really have no idea whatsoever as to what 'scope' currently does in dmdfe at all? T -- Meat: euphemism for dead animal. -- Flora
Re: DIP65: Fixing Exception Handling Syntax
On 7/9/2014 1:13 AM, Brian Schott wrote:
There is no ambiguity in the grammar. "catch (A) { ... }" is not valid. The spec
requires that you give the exception a name. A spec compliant D compiler MUST
parse your example code with the LastCatch rule. The fact that DMD does what it
does is a bug that has been documented for over a year.[1]
Sorry, I misunderstood. The relevant grammar is
https://dlang.org/statement#TryStatement :
Catches:
LastCatch
Catch
Catch Catches
LastCatch:
catch NoScopeNonEmptyStatement
Catch:
catch ( CatchParameter ) NoScopeNonEmptyStatement
CatchParameter:
BasicType Identifier
What the parser can do is do a lookahead on the ( ) to see if it matches the
'BasicType Identifier' grammar. Parser::isDeclaration() can be pressed into
service to do that. This should resolve the issue without breaking code.
BTW, the reason for LastCatch is that it long predates the splitting of
exceptions into the separate Error and Exception forks.
Re: Cool Stuff for D that we keep Secret
Coincidentally, this just got posted: "I thought I had a pretty good idea of what was happening in the D community - why haven't I heard more about digger? Sounds like a very useful. Has it only been a "one post to D.Announce"? Is it planned to be added to dtools? I could only find a reference as a link on wiki.dlang.org - no page by itself. You should really promote the tools you make!" http://www.reddit.com/r/programming/comments/2a8xf4/dconf_2014_day_2_talk_4_reducing_d_bugs_by/cisuuag
Re: Opportunities for D
On 7/9/14, 12:55 PM, Walter Bright wrote: On 7/9/2014 8:38 AM, Nick Treleaven wrote: On 08/07/2014 23:40, Remo wrote: What about the already present std.typecons.Unique? Unfortunately there are a lot of /+Doesn't work yet+/ comments in std.typecons.Unique code. I think it was written a long time ago. I think much of those parts will work now. I'm slowly going through them and will make more PRs, here's the first one, to disable postblit: https://github.com/D-Programming-Language/phobos/pull/2308 More things that need to happen with Unique: Unique!T u = ...; immutable p = u;// unique references can be implicitly cast to immutable Hmmm... how about using u after that? Andrei
Re: Opportunities for D
Walter Bright: That's essentially just adding an attribute, like: @nogc: to the beginning of a module. I think in the Java case it's more a package-level annotation instead of module-level one. Bye, bearophile
Re: Opportunities for D
Walter Bright: That's essentially just adding an attribute, like: @nogc: to the beginning of a module. It's not making it the default. Is it possible & useful & good to put something like a "@not_null_references:" (or a similar pragma) at the top of a module? How are differently defaulting modules going to interact with each other? (I think F# code originally had verbose syntax, plus a "#light" module annotation to allow the use of a lighter Haskell-like syntax with the same semantics. The light syntax was so popular that later the default mode was switched with the light mode.) Bye, bearophile
Re: Opportunities for D
On Wednesday, 9 July 2014 at 17:01:02 UTC, bearophile wrote: Dicebot: I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one. This article talks about switching to NotNull on default in real (small) Java projects (you have to add a @NonNullByDefault at package level to change the default): http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html Bye, bearophile I've used the Eclipse annotations with some success when writing Java code, which I do primarily for Android these days. If we were to ever transition to non nullable references by default, annotations would be a good way to make that transition. @notnull can be used to disallow setting null on references, so it can check for things like initialising a non-nullable reference in a constructor. @nullable would available for doing what is already true for references. Then Option(T) could be available as a library solution, which can hold a @nullable inside it and perform the necessary runtime checking and casting to @notnull T. Then you put things through a long deprecation cycle and the billion dollar mistake is finally corrected. There's a pipedream, anyway.
Re: Opportunities for D
On 7/9/2014 1:09 PM, H. S. Teoh via Digitalmars-d wrote: Surely the last question doesn't need *investigation* per se?? Or do we really have no idea whatsoever as to what 'scope' currently does in dmdfe at all? What I'm saying is there is not a design. A design needs to be created. Figuring out where we are, where we need to get to, and how to get there is what is needed. Please help.
Re: Opportunities for D
On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote: Hmmm... how about using u after that? Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.
Re: Opportunities for D
On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote: On 7/9/2014 3:20 AM, Dicebot wrote: I'd state it differently: "Marketing fuss about goroutines is the killer feature of Go" :) It does not have any fundamental advantage over existing actor model and I doubt it will matter _that_ much. Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature. I think it still mostly comes down to marketing :-) That said, we're pretty close in D once my Scheduler pull request is accepted. Between that and the Generator type in the same pull request, we're not missing much but the weird switch syntax they have. There's still some work to do, but I think a lot of it really comes down to showing people what's already possible in D rather than writing more code.
Re: Opportunities for D
On Wednesday, 9 July 2014 at 20:49:00 UTC, w0rp wrote: I should note that there is some merit to having Option(T) even without T being non-nullable by default, as it at least gives you the ability to look at an API and find out where you'll need to deal with the None case. T foo(); U bar(); V baz(); Doesn't say as much as. T foo(); Option!U bar(); V baz(); Even doing these things without strong compile time checks is a big step up.
Re: DIP65: Fixing Exception Handling Syntax
On Wednesday, 9 July 2014 at 20:11:46 UTC, Walter Bright wrote:
What the parser can do is do a lookahead on the ( ) to see if
it matches the 'BasicType Identifier' grammar.
Parser::isDeclaration() can be pressed into service to do that.
This should resolve the issue without breaking code.
There are 25 instances of code that does not follow the
"BasicType Identifier" syntax for CatchParameter in Phobos alone.
std/exception.d:126:catch (AssertError) assert(0);
std/exception.d:132:catch (AssertError) assert(0);
std/exception.d:138:catch (AssertError) assert(0);
std/exception.d:144:catch (AssertError) assert(0);
std/exception.d:153:catch (AssertError) thrown = true;
std/exception.d:164:catch (AssertError) thrown = true;
std/exception.d:175:catch (AssertError) thrown = true;
std/exception.d:187:catch (AssertError) thrown = true;
std/exception.d:218:catch (T)
std/exception.d:247:catch (AssertError) assert(0);
std/exception.d:261:catch (AssertError) assert(0);
std/exception.d:269:catch (AssertError) assert(0);
std/socket.d:1406:catch (SocketException)
std/conv.d:1509:catch (E)
std/format.d:2359:catch (UTFException)
std/stream.d:1382:catch (Throwable)
std/stream.d:1419:catch (Throwable)
std/array.d:2768:catch (Exception) assert(0);
std/array.d:2781:catch (Exception) assert(0);
std/array.d:2844:catch (Exception) assert(0);
std/array.d:2858:catch (Exception) assert(0);
std/array.d:3085:catch (Exception) assert(0);
std/range.d:5107:} catch (Throwable) { /* It's supposed
to throw.*/ }
std/range.d:5402:} catch (Exception) {}
std/range.d:9007:catch (Throwable)
Re: critique of vibe.d
Am Wed, 09 Jul 2014 17:28:42 + schrieb "Dicebot" : > On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote: > > Completely off-topic, but: > > > > Have you considered making vibe http-backend independent? > > So that it could provide a fcgi interface or be included in an > > nginx > > plugin? > > What is the benefit as opposed to using proxy_pass at nginx? fcgi > will be slower than built-in vibe.d HTTP server. FCGI was only an example. I guess the only benefit is that the webserver can spawn fcgi backends when it starts and files with certain extensions can be handled with these backends. But that's of course only useful with shared libraries / pages.
Re: critique of vibe.d
Am Wed, 09 Jul 2014 20:34:49 +0200 schrieb Sönke Ludwig : > Am 09.07.2014 19:03, schrieb Johannes Pfau: > > Am Wed, 09 Jul 2014 18:16:49 +0200 > > schrieb Sönke Ludwig : > > > >> Am 09.07.2014 17:26, schrieb Sean Kelly: > >>> On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: > Also, in playframework, vert.x and nodejs, they all have a > plugin/module system, that people could easily compose plugins to > make a website. (I call it plugin because that is what play used > to call it, now they all call it a module but that name will > easily conflict with D's sourcecode modules). This is a critical > mechanism that actually allured developers to contribute to the > eco-system. > >>> > >>> On a related note, one thing vibe.d is really missing from my > >>> perspective is a good way to handle unstable processes and perform > >>> seamless code upgrades (this is where Erlang really shines IMO). > >>> It would be cool if there were a process monitor at least. The > >>> system I work with does some fancy stuff with UDS, but that > >>> probably isn't necessary. I'll admit that the ball is probably > >>> kind of in my court here, since IPC would be a handy way of > >>> communicating process health, but something simpler using pipes > >>> or whatever would work as well. > >> > >> This is what vibedist [1] was/is intended for, but unfortunately I > >> never found the time to really finish it so far. > >> > >> [1]: https://github.com/rejectedsoftware/vibedist > > > > > > Completely off-topic, but: > > > > Have you considered making vibe http-backend independent? > > So that it could provide a fcgi interface or be included in an nginx > > plugin? > > That could be done pretty easily by providing an alternative to > listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)). > It could use the HTTPServerRequest and HTTPServerResponse classes > more or less just like the HTTP server does. > > > > > Also as D plugins now seem to work more or less have you considered > > loading webpages dynamically from .so files? > > > > Then we could invent some file extension - like .dpage - and have > > one vibe fcgi process handle all .dpage files. The process then > > simply loads the .dpage shared library, calls some function > > (extern(C) IWebSite vibe_get_site()) etc. > > > > Basically the way asp.net works, IIRC. > > > > That would be pretty much what Rikki Cattermole is planning to do > with Cmsed [1]. For vibe.d it would be a bit too much at this time. > There is still a lot that I would like to get done on the lower > levels of the library, so that the basis is really solid sooner > rather than later. The highest level features planned for now are the > descriptive REST and web interface modules. > > However, there is a plan for using dynamic libraries to support > seamless live editing/reloading of individual Diet templates [2]. > > [1]: http://code.dlang.org/packages/cmsed > [2]: https://github.com/rejectedsoftware/vibe.d/issues/676 I see, thanks. I think a CMS is usually a little higher-level then what I meant. But of course a name doesn't say much about what a project actually is ;-)
Re: [OT] Re: Redesign of dlang.org
On 09/07/2014 4:43 PM, Chris wrote: This sounds just like Imperial education. Very interesting how it equates Imperial practices with the "right" thing and the (continental) arch enemy with the "wrong" thing. By the way, there was a reason why combatant riders would ride on the right side on a tilting yard: they were right-handed. Just as it makes more sense to switch gears with the right hand and not with the (in most cases) weaker left hand. Sorry, the correct side/wrong side designations was all me, I have trouble with light and reft, and didn't want to get mixed up with the 2 meanings of right. Perhaps its an artefact of my imperial education ^^ Also some argue that it makes more sense in a modern car to change gear with the left hand and keep the stronger arm on the steering wheel. Early right-hand-drive cars either had all foot operated gears, or they were on the outside (actually outside the cockpit) rather than in the middle because they needed real effort, modern gears especially automatics don't need that effort any more. A...
Re: Opportunities for D
Am Wed, 9 Jul 2014 13:09:30 -0700
schrieb "H. S. Teoh via Digitalmars-d" :
> Speaking
> > >of which, what *is* the current extent of the implementation of
> > >'scope'? I assume it isn't just a no-op, since I see it applied to
> > >delegate parameters every now and then?
> >
> > Yes, yes, yes, ... these are questions that all need investigation
> > and answering.
>
> Surely the last question doesn't need *investigation* per se?? Or do
> we really have no idea whatsoever as to what 'scope' currently does in
> dmdfe at all?
So this was not a rhetoric question?
For delegates scope can prevent closure heap allocation. For all other
types it does nothing. Example:
import std.stdio;
void testA(void delegate() cb)
{
cb();
}
void testB(scope void delegate() cb)
{
cb();
}
void main()
{
int a;
void callback() {a = 42;}
//Callback accesses a, testA might store a reference to callback
//->a might be accessible after this main function returns
//->can't keep it on the stack. Allocate a on the heap
testA(&callback);
//Callback accesses a, but testB does not store a reference
//as it tells us by using scope
//So as soon as testB returns, there's no reference to a floating
//around and we can allocate a on the stack.
//(Of course as long as we call testA in this function, a is always on
// the heap. but if we only call testB it can be on the stack)
testB(&callback);
}
Re: PHP extension in D
Hello! I've reproduced steps 1-9 on my Ubuntu 14.04 x64 machine, but now I have this errors: root@dlang:~/phpext# dmd -shared speedup_wrap.o dfakemain.o speedup.o -ofspeedup.so /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(lifetime_485_6c8.o): relocation R_X86_64_32 against `_D15TypeInfo_Shared7__ClassZ' can not be used when making a shared object; recompile with -fPIC /usr/lib/x86_64-linux-gnu/libphobos2.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status --- errorlevel 1 I'm new to D/C languages, so what can I do to fix this error? I tried to compile with "-fPIC" option at all appropriate steps, but nothing helps :(
