Programming in D book, User Defined Attributes (UDA) chapter
I made some additions and corrections. The following are the major ones: * The 'User Defined Attributes (UDA)' chapter * @nogc * foreach_reverse * Formatted element output with %( and %) * static this, static ~this, shared static this, and shared static ~this As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali
Re: Programming in D book, User Defined Attributes (UDA) chapter
On Tue, 26 Aug 2014 23:16:14 -0700 Ali Çehreli via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: * The 'User Defined Attributes (UDA)' chapter great! * static this, static ~this, shared static this, and shared static ~this and this too. signature.asc Description: PGP signature
Re: Programming in D book, User Defined Attributes (UDA) chapter
On Tue, 26 Aug 2014 23:16:14 -0700 Ali Çehreli via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: * Formatted element output with %( and %) by the way, i never knows about this feature. maybe i should RTFM someday... signature.asc Description: PGP signature
Re: core.stdcpp
On 8/26/2014 5:32 PM, Mike wrote: We currently have std.c and core.stdc. I believe core.stdc should be migrated to std.c, not the other way around. And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead. The irony is D1 has std.c, and for D2 it was migrated to core.stdc. Moving it back in an endless search for taxonomical perfection just jerks the users around. We've done a lot of renaming in the runtime library, and an awful lot of ink has been spilled on the subject in these forums. But I'm not aware of a single user gained by these changes, and I suspect we've lost a few, not because they didn't like the newer names, but because they disliked the constant disruption of their code base.
Re: core.stdcpp
eles wrote in message news:ybcxmuwwpsiyupwer...@forum.dlang.org... The question of dupplication may be addressed now better, since the newly fixed bug about hierarchical packaging. I don't see how. _only that_ should be the runtime. And the sole part that one needs to port in order to claim having a full port of the D language (that is, the compiler). These are the tires of the cars, the things that touch the ground. Everything else is optional. (Pirelli had a nice advertisemnt with this line) Well, I agree it absolutely has to be in druntime. And, to go further, only c/OS bindings required for this are to be embedded at this level. Requiring full c/OS bindings in druntime is so useful, and it costs us so little. Besides a warm fuzzy feeling, not requiring them seems to only benefit D implementations for theoretical platforms that probably don't exist. Phobos shall be 100% optional, otherwise you don't have a language, but a framework. This is the separation line: the runtime is a must for the language, the standard library is not. If in doubt wether one piece belongs, cut here. Call it what you want. Phobos is supposed to be 100% optional but it currently is not. We get to decide where the line goes, and with D it is almost always decided on usefulness, not correctness. Requiring c bindings is useful.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 07:52:18 UTC, Daniel Murphy wrote: eles wrote in message news:ybcxmuwwpsiyupwer...@forum.dlang.org... Requiring full c/OS bindings in druntime is so useful, and it costs us so little. But the request is simply to split the current druntime in a language-runtime and a phobos-runtime. The namespace and so on might even remain the same and the existing code would run unmodified. What is really important is that a clear separation exists between the two *inside* the implementation. The users of D are not concerned about that, the compiler designers are. Have, as now, the language-runtime + the phobos-runtime calles as druntime. Why does bother you a re-modularization of druntime? Besides a warm fuzzy feeling, not requiring them seems to only benefit D implementations for theoretical platforms that probably don't exist. One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). If you make porting harder, then you can safely bet that those ports won't ever exist. But is this truly what we want?
Re: core.stdcpp
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: On 8/26/2014 5:32 PM, Mike wrote: Moving it back in an endless search for taxonomical perfection Well, keeping things in limbo for such many years (@property, anyone?) is not going to help neither. I agree it is a fine balance between changing for better consistency and conserve for compatibility. Still, some changes are small and would solve problems for the many years to come. I still cannot forget that decision to keep the flawed std.uni name instead of a std.unicode name. It wasn't even costly. But, well... And one day from now you will write The paradox is that at one moment we decided to keep the std.uni name because of taxonomical compatibility etc. etc. etc.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: On 8/26/2014 5:32 PM, Mike wrote: We currently have std.c and core.stdc. I believe core.stdc should be migrated to std.c, not the other way around. And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead. The irony is D1 has std.c, and for D2 it was migrated to core.stdc. ...and design takes the backseat to convenience. Moving it back in an endless search for taxonomical perfection just jerks the users around. We've done a lot of renaming in the runtime library, and an awful lot of ink has been spilled on the subject in these forums. But I'm not aware of a single user gained by these changes, and I suspect we've lost a few, not because they didn't like the newer names, but because they disliked the constant disruption of their code base. I completely understand and sympathize. This is most unfortunate.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 02:17:39 UTC, Dicebot wrote: On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote: What do you think about following compromise: 1) C bindings are defined in spec to be optional 2) They are still kept in druntime repo but declared an implementation detail 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own. It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation. By C bindings do you really mean C/C++ bindings given the context of this thread? Yeah, any external / OS bindings is probably more appropriate wording. It's a step in the right direction, but ultimately just a formality. Maybe that's the best I can hope for.
Re: core.stdcpp
eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org... But the request is simply to split the current druntime in a language-runtime and a phobos-runtime. The namespace and so on might even remain the same and the existing code would run unmodified. What is really important is that a clear separation exists between the two *inside* the implementation. The users of D are not concerned about that, the compiler designers are. Have, as now, the language-runtime + the phobos-runtime calles as druntime. Why does bother you a re-modularization of druntime? I disagree that it's important, or even useful. One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). An embedded system that can support all of D but doesn't have a cruntime? I don't believe it. If it has a cruntime then providing bindings is a non-issue, and if it can't support all of D then supporting only a subset (and then being free to exclude core.stdc) is inevitable. If you make porting harder, then you can safely bet that those ports won't ever exist. But is this truly what we want? I think it's more likely that those ports won't exist because those platforms don't exist.
DMD v2.067.0-b1
Hello all, Binaries for beta 1 is available for download and testing. You can find them at: http://wiki.dlang.org/Beta_Testing Test!!! Document bugs/regressions!!! Enjoy!!! Thanks to those who have contributed to the maintenance/upkeep of the wiki page. As I am no a full-time student with an overly aggressive class schedule, I am finding less and less time to keep track of what is going on. I appreciate the assistance. Andrew
Re: DMD v2.067.0-b1
On 8/27/2014 2:19 PM, Andrew Edwards wrote: Hello all, Binaries for beta 1 is available for download and testing. You can find them at: http://wiki.dlang.org/Beta_Testing Test!!! Document bugs/regressions!!! Enjoy!!! Thanks to those who have contributed to the maintenance/upkeep of the wiki page. As I am no a full-time student with an overly aggressive class schedule, I am finding less and less time to keep track of what is going on. I appreciate the assistance. Andrew There has been a lot of valid criticism about us releasing 2.066 with outstanding regressions. https://issues.dlang.org/buglist.cgi?bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDlist_id=88763query_format=advanced Fixes exist: https://github.com/D-Programming-Language/dmd/pull/3884 https://github.com/D-Programming-Language/dmd/pull/3879 Let's get them reviewed/pulled and do a 2.066 point release.
Re: DMD v2.067.0-b1
On Wednesday, 27 August 2014 at 21:22:42 UTC, Walter Bright wrote: On 8/27/2014 2:19 PM, Andrew Edwards wrote: Hello all, Binaries for beta 1 is available for download and testing. You can find them at: http://wiki.dlang.org/Beta_Testing Test!!! Document bugs/regressions!!! Enjoy!!! Thanks to those who have contributed to the maintenance/upkeep of the wiki page. As I am no a full-time student with an overly aggressive class schedule, I am finding less and less time to keep track of what is going on. I appreciate the assistance. Andrew There has been a lot of valid criticism about us releasing 2.066 with outstanding regressions. https://issues.dlang.org/buglist.cgi?bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDlist_id=88763query_format=advanced Fixes exist: https://github.com/D-Programming-Language/dmd/pull/3884 https://github.com/D-Programming-Language/dmd/pull/3879 Let's get them reviewed/pulled and do a 2.066 point release. Very true but this does not conflict with 2.067 cycle (other than competing for attention of compiler developers)
Re: core.stdcpp
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: On 8/26/2014 5:32 PM, Mike wrote: We currently have std.c and core.stdc. I believe core.stdc should be migrated to std.c, not the other way around. And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead. The irony is D1 has std.c, and for D2 it was migrated to core.stdc. Moving it back in an endless search for taxonomical perfection just jerks the users around. We've done a lot of renaming in the runtime library, and an awful lot of ink has been spilled on the subject in these forums. I don't think the problem here is about naming. Both std.c and core.stdc are good. The problem is that you don't always want to bring libc and libstdc++ with you with every single project you write. Thus it shouldn't be in the runtime (except the very bit you can't get rid of). It can still be core.stdc .
Re: DMD v2.067.0-b1
On 8/27/2014 2:27 PM, Dicebot wrote: Let's get them reviewed/pulled and do a 2.066 point release. Very true but this does not conflict with 2.067 cycle (other than competing for attention of compiler developers) You're right, somehow I misread 2.067 as 2.066. My mistake.
Re: DMD v2.067.0-b1
Does this 2.67 release contain COFF32, and the new package fix? On 28 August 2014 07:45, Walter Bright via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 8/27/2014 2:27 PM, Dicebot wrote: Let's get them reviewed/pulled and do a 2.066 point release. Very true but this does not conflict with 2.067 cycle (other than competing for attention of compiler developers) You're right, somehow I misread 2.067 as 2.066. My mistake.
Re: Voting: std.logger
Am Wed, 27 Aug 2014 01:09:21 + schrieb Dicebot pub...@dicebot.lv: On Wednesday, 27 August 2014 at 00:09:15 UTC, Marco Leise wrote: As far as I know, exactly this is not possible with the current GC implementation. The exception you catch there has just been allocated somewhere deeper in the log function. But all GC allocations in a GC invoked dtor cause MemoryErrors and program abortion/crashes. :( In a perfect world I'd imagine you can set up a fallback logger. So if the disk is full an exception is thrown by e.g. std.stdio.File, which is passed as an error level log message to the fallback logger, which might write to stderr: ERROR: Could not write the following message to logXYZ: message The reason was: Disk full I don't think it will help either. The very moment exception is allocated inside std.stdio.File your program will crash, it won't get to fallback. Only solution is to implement your logger as @nothrow thing by using only C functions internally instead of std.stdio - something that feels overly limited for a general use case. Exactly, I just needed someone else to speak it out. :) I really think this is the case where you should roll your own FileNoThrowingLogger and go with it. *Me* or everyone who needs to log something in a dtor? In a long term this is something much better to be fixed in GC implementation than constantly hacked in stdlib modules. Or is this maybe the other language change (besides not generating code for unused lambdas) that should be pushed with std.log, because otherwise it will never be solved ? I don't know, but no logging in dtors is a serious and hard to sell limitation. Not the author's fault though. -- Marco
Re: Before we implement SDL package format for DUB
On 27/08/14 07:40, eles wrote: But we could imagine a declarative layer in/over D or a module directed at it. You know, one language to rule them all (including declarative languages, just as the functional ones...). You could probably come quite far with UDA's or similar. -- /Jacob Carlborg
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Tuesday, 26 August 2014 at 21:30:40 UTC, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 I don't like that. Even if we want to break this patent with prior art, we need to publish one for ourselves. This system sucks, we can't choose not to be part of it if we want to be protected. And do we have the money to publish patents anyway? I feel pretty bad about this. What are the thoughts of Andrei and Walter on this stuff?
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 12:11 AM, via Digitalmars-d wrote: On Tuesday, 26 August 2014 at 21:30:40 UTC, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 I don't like that. Even if we want to break this patent with prior art, we need to publish one for ourselves. This system sucks, we can't choose not to be part of it if we want to be protected. And do we have the money to publish patents anyway? I feel pretty bad about this. What are the thoughts of Andrei and Walter on this stuff? In the US, filing a patent app requires about $10k and a good lawyer. It's not in the realm of most small entities to do. It's a seriously bad use of $10k. The best defense is prior art, and there's a ton of it. I say this having my name on a handful of applications and one granted patent.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky
wrote:
That's somewhat misleading.
More accurately, SDL is newline-delimited (with backslash line
continuation). That's pretty darn simple and has an age-old
history. It's not like we're talking weird Python/JavaScript
rules or anything here.
The only thing that does trip people up is that the existence
of { and } in the syntax makes people think C-family and
therefore freeform. And then it isn't, so that makes them
angry. Yeeargh! Hulk Not Want! Well...or something vaguely
sorta kinda like that ;)
That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line
continuations.
- XML is XML. I find it actually OK.
I would support this. Yes, is verbose, we know that. But is a
very solid
foundation.
XML is the spawn of satan. And not the cool rock n roll,
heavy metal kind of satan, or the bumbling lovable DBZ Mr.
'Hercule' Satan either, but the hey, let's write a commercial
webserver in shell scripts kind of raw pulsating evil.
What's wrong with XML? I work with it daily and see no problem.
The less syntax a language has, the worse it scales, and if it
doesn't scale, its adoption creates a technical debt. 100 lines
with 3 levels of nesting and JSON becomes hard to follow and TOML
becomes simply unmanageable.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote: On 8/27/2014 1:40 AM, eles wrote: On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote: On 8/26/2014 1:43 PM, eles wrote: On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote: Am 26.08.2014 15:37, schrieb eles: On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote: On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote: All reasonable points, but it still seems like swatting a fly with a bazooka. ;) Well, you need a sharp eye and a sure hand. But otherwise, the sole problem is if the fly is on someone's nose...
Re: Voting: std.logger
On Tuesday, 26 August 2014 at 19:39:26 UTC, Marco Leise wrote: Am Tue, 26 Aug 2014 18:23:30 + schrieb Dicebot pub...@dicebot.lv: On Tuesday, 26 August 2014 at 15:44:19 UTC, Robert burner Schadek wrote: BTW: Someone else mentioned it before: Logging in destructors would be a requirement for me, too. It would be a pity to have forbidden spaces for logging. I very much like the fact that use of printk() is so much ubiquitous.
Re: What have I missed?
On Saturday, 9 August 2014 at 07:21:28 UTC, Era Scarecrow wrote: On Saturday, 9 August 2014 at 07:12:45 UTC, eles wrote: Things will be easier when it clicks for me i'm sure. Re-reading part of the book, a portion of it, the designs behind Git makes sense, but there's no 'ah ha!' moment, not yet. How is this going?
Re: OT Java stuff [was Using D]
On Tuesday, 26 August 2014 at 22:07:49 UTC, Jeremy Powers via Digitalmars-d wrote: If your users are having to install things then the problem is your deployment mechanism not the JVM dependency hell system. Java deployments are actually really quite easy. Either you package a total system with all dependencies and provide entry scripts, or you use Maven Central (or increasingly BinTray) for accessing dependencies. If I need deployment mechanisms like the ones above, then there's something wrong with the language. All these crutches and patches. To set up and test a deployment mechanism takes as long as writing the program. No thank you. This is what you get with shared libraries. If you don't want to deal with dependencies, either A) ship a static-linked binary or B) cross your fingers and pray. Statically linked binaries are still the best option, if you want to make sure things will work for the user (and you don't have time for customer service). It's also a good strategy for cross-platform development, this or you have to use an approach similar to Textadept that ships everything in one package. I usually ship all the additional dlls / libs, if there are any. Relying on system wide dynamic linking is more for cases when you develop for one particular environment or when you're 90% sure that a certain library exists on most systems you develop for. The C standard library comes to mind, but even there are differences between Linux and Windows. And don't forget that, unlike Linux users, people who use Windows are usually not tech savvy in the sense that they can deal with downloading additional libraries. It all depends on the products you're developing. But for our stuff it's better to go static or ship everything. I've found the java ecosystem to be quite well fleshed out and mature in handling lib/jar dependencies, such that it was an unpleasant shock dealing with C++ after years away. Using maven, for instance, is a quick and easy way to abstract the problems away (though it is better suited for builds than deployments). As D gets more support for dynamic libraries, it would be good to take lessons from how Java and others have dealt with dependency management. Yes, only better. :-)
Re: problem creating a 32-bit dll
but then does that mean the linker already link user32.lib? On Wednesday, 27 August 2014 at 05:42:06 UTC, kdmult wrote: On Tuesday, 26 August 2014 at 20:41:27 UTC, nezih wrote: Thanks! That did the trick. Btw do you have any idea about getting rid of the linker's warning message about the user32.lib? I played with the LIB env variable in several ways and I also edited sc.ini to set the LIB but no luck so far. Just remove -Luser32.lib from the command line.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Tuesday, 26 August 2014 at 21:29:13 UTC, Nick Sabalausky wrote: On 8/26/2014 4:34 PM, Chris wrote: On Tuesday, 26 August 2014 at 19:37:29 UTC, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. That's why I absolutely love MS! It's FAR more than just MS. For example, Apple's just as bad. Just look at Steve Job's undying vendetta against Google (by way of Samsung as a proxy target). Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 03:00:26 UTC, Nick Sabalausky wrote: On 8/26/2014 6:52 PM, Rikki Cattermole wrote: You guys should totally move to New Zealand. Seriously you would fit right in. Best part? No software patents. Nice. I've heard that a lot of the scenery is stunning over there, too. Slow and expensive electronics importing AIUI, but maybe that'd be in my best interest anyway...biggest thing to raise my blood pressure lately was my last trip to MicroCenter[1]. Take it easy. The most important things are the ideas and the software. The latests gadgets are for users :-) As soon as I finally snap and go all luddite hermit or something, maybe that's where I'll retire ;) New Zealand that is, not MicroCenter. Swapping your chip for sheep. [1] http://www.microcenter.com/site/stores/default.aspx
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: On Tuesday, 26 August 2014 at 21:29:13 UTC, Nick Sabalausky wrote: On 8/26/2014 4:34 PM, Chris wrote: On Tuesday, 26 August 2014 at 19:37:29 UTC, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. That's why I absolutely love MS! It's FAR more than just MS. For example, Apple's just as bad. Just look at Steve Job's undying vendetta against Google (by way of Samsung as a proxy target). Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:20:49 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence. Big companies file patents. All of them do. That's just the way it is. I wouldn't see anything more to it than that. It's not some conspiracy or corporate war. That's the way the game is played. We just need to make sure we don't become the losers here. It would help to have input from Walter here though: It's his language, and, AFAIK, he also happens to be savvy with this kind of stuff.
Re: Before we implement SDL package format for DUB
Am 27.08.2014 10:02, schrieb Kagamin:
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:
That's somewhat misleading.
More accurately, SDL is newline-delimited (with backslash line
continuation). That's pretty darn simple and has an age-old history.
It's not like we're talking weird Python/JavaScript rules or anything
here.
The only thing that does trip people up is that the existence of { and
} in the syntax makes people think C-family and therefore freeform.
And then it isn't, so that makes them angry. Yeeargh! Hulk Not Want!
Well...or something vaguely sorta kinda like that ;)
That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line continuations.
Like JavaScript for example?
- XML is XML. I find it actually OK.
I would support this. Yes, is verbose, we know that. But is a very solid
foundation.
XML is the spawn of satan. And not the cool rock n roll, heavy
metal kind of satan, or the bumbling lovable DBZ Mr. 'Hercule'
Satan either, but the hey, let's write a commercial webserver in
shell scripts kind of raw pulsating evil.
What's wrong with XML? I work with it daily and see no problem. The less
syntax a language has, the worse it scales, and if it doesn't scale, its
adoption creates a technical debt. 100 lines with 3 levels of nesting
and JSON becomes hard to follow and TOML becomes simply unmanageable.
The reason to search for an additional format is to make it more
convenient and readable for human interaction. XML wouldn't structurally
a bad choice, but is awful because of it's syntactical overhead.
Re: Before we implement SDL package format for DUB
Am 27.08.2014 10:29, schrieb eles: On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote: On 8/27/2014 1:40 AM, eles wrote: On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote: On 8/26/2014 1:43 PM, eles wrote: On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote: Am 26.08.2014 15:37, schrieb eles: On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote: On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote: All reasonable points, but it still seems like swatting a fly with a bazooka. ;) Well, you need a sharp eye and a sure hand. But otherwise, the sole problem is if the fly is on someone's nose... And you will have to pay the price for a rocket and have to rebuild parts of your house every time you kill a fly ;)
Re: An idiom for disabling implicit conversions
On Tuesday, 26 August 2014 at 18:29:49 UTC, Uranuz wrote:
On Tuesday, 26 August 2014 at 16:48:08 UTC, Timon Gehr wrote:
On 08/26/2014 05:46 PM, Uranuz wrote:
In the pre-last paragraph please read text^
Also notice that C is language with weak type system but D is
declared to have type system.
as:
Also notice that C is language with weak type system but D is
declared to have *strong* type system.
It's not _that_ strong. Also, this is a library problem.
I'd suggest you file a bug report/enhancement request against
Phobos, if it is not already there.
https://issues.dlang.org/
It seems that adding some constructor(s)/opAssign(s) to
Nullable will solve this problem.
( BTW: You are more likely to get a quick response if your
post looks a little bit more digestible, like:
On 08/26/2014 05:38 PM, Uranuz could have written:
// ---
import std.typecons;
void main(){
Nullable!ubyte x;
Nullable!int y=x; // AssertError: Called 'get' on null
Nullable!ubyte
}
// ---
import std.typecons;
void main(){
Nullable!ubyte x;
Nullable!int y;
y=x; // AssertError: Called 'get' on null Nullable!ubyte
}
// ---
Is this a bug?
Or you could have gone straight to https://issues.dlang.org/.
:) )
The last example is even more obvious but didn't come to my
mind. Maybe I'l think of better implementation myself and push
something to standard library.
The best way to make something working is to do it myself
[jokingly]
If I could write multiple alias this in Nullable I could create
implicit conversions from Nullable!byte not only to byte but also
to Nullable!short, Nullable!int. In this case there is no need to
implement lots of overloads for property of type Nullable!int in
order to correctly accept Nullable!byte, Nullable!ubyte and so
on. I have wrote an example code and seems that only fixing
Nullable implementation will not help to eliminate the problem I
was talking about.
So I have a choice:
1. Implement Nullable type without *alias this* at all (and
access to internal value with getter method or property)
2. Implement lots of overloads of virtual Nullable!int property
to accept every minor integer types.
Also is needed to forbid Nullable!uint conversion because it is
incorrect. I can't correctly store uint.max inside int variable,
but implicit coversion is allowed in the compiler (and it is not
documented).
Because using alias this makes code shorter I prefer it, although
it is very tricky feature and needs attention during development.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:28:17 UTC, monarch_dodra wrote: On Wednesday, 27 August 2014 at 09:20:49 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence. Big companies file patents. All of them do. That's just the way it is. I wouldn't see anything more to it than that. It's not some conspiracy or corporate war. I don't share your optimism. That's the way the game is played. We just need to make sure we don't become the losers here. It would help to have input from Walter here though: It's his language, and, AFAIK, he also happens to be savvy with this kind of stuff.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:28:17 UTC, monarch_dodra wrote: On Wednesday, 27 August 2014 at 09:20:49 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence. Big companies file patents. All of them do. That's just the way it is. I wouldn't see anything more to it than that. It's not some conspiracy or corporate war. That's the way the game is played. We just need to make sure we don't become the losers here. It would help to have input from Walter here though: It's his language, and, AFAIK, he also happens to be savvy with this kind of stuff. Their brand new type qualifier is the same as D's one. They even copied the name immutable. Maybe it's part of a strategy, maybe not. In any case it's a thief, I don't like this word because you can't steal an idea, but they took ownership of it.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 09:33:19 UTC, Sönke Ludwig wrote: Am 27.08.2014 10:29, schrieb eles: On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote: On 8/27/2014 1:40 AM, eles wrote: On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote: On 8/26/2014 1:43 PM, eles wrote: On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote: Am 26.08.2014 15:37, schrieb eles: On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote: On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote: And you will have to pay the price for a rocket and have to rebuild parts of your house every time you kill a fly ;) If it's 3 AM and you cannot yet sleep because that fly is annoying you, I bet you'll consider that's a very small price to pay...
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote: Am 27.08.2014 10:02, schrieb Kagamin: On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote: The reason to search for an additional format is to make it more convenient and readable for human interaction. There is also this quest: http://www.gnu.org/software/recutils/
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 09:36:30 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:28:17 UTC, monarch_dodra wrote: On Wednesday, 27 August 2014 at 09:20:49 UTC, Théo Bueno wrote: On Wednesday, 27 August 2014 at 09:08:24 UTC, Chris wrote: Of course, the whole lot of them! I only wonder who they're trying to attack here? It must be some sort of strategy to put someone they deem dangerous off his stride. Probably the open source community and / or a competitor. I don't know the laws in the US and don't know how serious this is. It probably can't just be ignored. Is there some other big company they're trying to get at with this? Maybe they're preparing a counter strike. Yeah, IMO these patents can't be a coincidence. Big companies file patents. All of them do. That's just the way it is. I wouldn't see anything more to it than that. It's not some conspiracy or corporate war. That's the way the game is played. We just need to make sure we don't become the losers here. It would help to have input from Walter here though: It's his language, and, AFAIK, he also happens to be savvy with this kind of stuff. Their brand new type qualifier is the same as D's one. They even copied the name immutable. Maybe it's part of a strategy, maybe not. In any case it's a thief, I don't like this word because you can't steal an idea, but they took ownership of it. From a linguistic point of view it is only logical one should come up with the word immutable in this context. If something (data, objects) are not mutable they are immutable (this may sound trivial but it is not). I suppose they filed the patent, because concurrency, thread safety and multi core programming have become so important over the last couple of years, and because it has become clear that some sort of immutable type is needed. Thus, they seek to get ownership of the word/idea/concept (which is ridiculous of course) to (pre-emptively) knock out others (or get money for it by licensing it to others, including those they stole it from). A shame, really.
Re: Before we implement SDL package format for DUB
I just had an epiphany. I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON.
Re: problem creating a 32-bit dll
Answering my own question: seems like the 32-bit binary gets linked against user32.lib even though I don't specify -Luser32.lib, but I have to specify that for the 64-bit build. On Wednesday, 27 August 2014 at 09:01:12 UTC, nezih wrote: but then does that mean the linker already link user32.lib? On Wednesday, 27 August 2014 at 05:42:06 UTC, kdmult wrote: On Tuesday, 26 August 2014 at 20:41:27 UTC, nezih wrote: Thanks! That did the trick. Btw do you have any idea about getting rid of the linker's warning message about the user32.lib? I played with the LIB env variable in several ways and I also edited sc.ini to set the LIB but no luck so far. Just remove -Luser32.lib from the command line.
Re: Before we implement SDL package format for DUB
Am 27.08.2014 11:49, schrieb eles: On Wednesday, 27 August 2014 at 09:33:19 UTC, Sönke Ludwig wrote: Am 27.08.2014 10:29, schrieb eles: On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote: On 8/27/2014 1:40 AM, eles wrote: On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote: On 8/26/2014 1:43 PM, eles wrote: On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote: Am 26.08.2014 15:37, schrieb eles: On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote: On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote: And you will have to pay the price for a rocket and have to rebuild parts of your house every time you kill a fly ;) If it's 3 AM and you cannot yet sleep because that fly is annoying you, I bet you'll consider that's a very small price to pay... But the next morning you'll wake up and regret what you did that night
Re: Before we implement SDL package format for DUB
Am 27.08.2014 11:47, schrieb eles: On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote: Am 27.08.2014 10:02, schrieb Kagamin: On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote: The reason to search for an additional format is to make it more convenient and readable for human interaction. There is also this quest: http://www.gnu.org/software/recutils/ It seems to be missing built-in array types and nested maps/objects. It *looks* like it would require defining so many custom types that it would become a de-facto custom format. Still looks interesting in general, though.
Re: RFC: scope and borrowing
Marco Leise:
The amount of possible use-cases you listed for this extension
is staggering.
With scope management in code like this:
import std.stdio, std.algorithm;
int foo(in int[] a) {
return sum([0, 1] ~ a[1 .. $ - 2] ~ 0 ~
[a[$ - 1] + 1, a[$ - 1] + 2]);
}
void main() {
int[5] b = [10, 20, 30, 40, 50];
b.foo.writeln;
}
The compiler in theory could lower the code to something like
this, removing all heap allocations for the array literals and
the concatenations, allowing 'foo' to be annotated with @nogc (I
don't know if Rust is able to do this, I presume it can):
import std.stdio, std.algorithm, core.stdc.stdlib;
T foo(T)(in T[] a) @nogc {
immutable size_t L = 2 + a.length - 3 + 1 + 2;
auto ptr = alloca(T.sizeof * L);
if (ptr == null)
exit(1); // Or throw a stack overflow error.
T[] b = (cast(T*)ptr)[0 .. L];
b[0] = 0;
b[1] = 1;
b[2 .. $ - 3] = a[1 .. $ - 2];
b[$ - 3] = 0;
b[$ - 2] = a[$ - 1] + 1;
b[$ - 1] = a[$ - 1] + 2;
return sum(b);
}
void main() {
int[5] c = [10, 20, 30, 40, 50];
c.foo.writeln;
}
But in some cases you don't want those arrays to be allocated on
the stack because you know they are very large. So the [...]s
array literal syntax becomes useful again:
import std.stdio, std.algorithm;
int foo(const scope int[] a) {
return sum([0, 1]s ~ a[1 .. $ - 2] ~ 0 ~
[a[$ - 1] + 1, a[$ - 1] + 2]s);
}
But this is still not enough, because even if those parts are all
safely stack-allocated, the result of the concatenation is still
not stack-allocated.
This could be enough:
import std.stdio, std.algorithm;
int foo(const scope int[] a) @nogc {
auto[$] a2 = [0, 1]s ~ a[1 .. $ - 2] ~ 0 ~
[a[$ - 1] + 1, a[$ - 1] + 2]s;
return sum(a2[]);
}
Bye,
bearophile
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 11:29:32 UTC, Sönke Ludwig wrote: Am 27.08.2014 11:49, schrieb eles: But the next morning you'll wake up and regret what you did that night Well, that saying could be applied to so many things in life...
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: I just had an epiphany. I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery Why to not use a classic? Within C++, there is a much smaller and cleaner language struggling to get out. He meant, of course, D. We knew it all along.
Re: Before we implement SDL package format for DUB
On Monday, 25 August 2014 at 22:14:59 UTC, Idan Arye wrote: About the language - if you are making a new data serialization language(NOT markup language. These languages don't actually mark anything up) for DUB, could you please make it support heredocs? This will allow, in the future, to easily add pre-build and post-build scripts directly in the build-file. If it's something non-trivial, it should be put into separate file at least to get dedicated syntax highlighting and editor support.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote:
That's justified, because SDL fails to not surprise. Curly
brace
syntaxes are not line-delimited not requires backslash line
continuations.
Like JavaScript for example?
You mean its feature where it can work without semicolons? Yeah,
that's a silly feature, but it's not forced on everyone. I have
never hit it in my code.
The reason to search for an additional format is to make it
more convenient and readable for human interaction. XML
wouldn't structurally a bad choice, but is awful because of
it's syntactical overhead.
Aren't people more concerned with writing XML rather than
reading? Syntax makes for easier reading and tedious writing.
And overhead is not really big:
menu: { id: file, value: File }
menu id=file value=File/
It's even shorter!
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 05:40:51 UTC, eles wrote:
On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky
wrote:
All it would do is provide many tempting and creative ways to
accidentally obfuscate the package description file.
I agree partially with this, this is why I am not pushing for
D. A declarative language seems to be more appropriate in this
case.
Ideally we wouldn't even need that, but reality is rarely so
kind. I suppose if we can't be sufficiently Perl-like, maybe
Portage-like is the next best thing. :/
Thought dump:
The DUB package specification is versioned, right? So, in the
vein of the Package Manager Specification, for a given...let's
call it DUBAPI version... provide higher-level functions that
abstract away things that are common or things that are tricky to
get right if you try to always do them manually. Package them in
modules that can be imported and use the DUBAPI version within
the module to select version-specific behaviour. For those of
stern fortitude, an ugly ebuild-like thing; a...uhm, dubuild:
DUBAPI=1;
import dub.autotools;
import dub.git;
import dub.utils : patch;
DESCRIPTION = Plugin providing semi-solids for bread;
HOMEPAGE = http://toa.st/spread;;
LICENSE = zlib;
PHOBOS_VERSION = =2.065; // TODO: fix the failure
GIT_REPO_URI = http://github.com/toast/spread;;
GIT_BRANCH = butter; // Vars defined in the dub.git module
DEPEND = {=libyeast-1.3, =libbread-2.2 }; // Build-time
dependency
// Each of these phase functions overrides a default.
// If it doesn't need overridden, the default is used.
src_unpack(){
git_fetch(GIT_BRANCH); // No argument gets master branch
patch(files/melt_butter.patch); // Apply our local patch
}
src_configure() {
assert(autoreconf(), configure failed!); // Die if this
fails.
}
src_install() {
dub_install(~/toast/plugins/); // Non-standard location
}
post_install() {
dublog(Activate the spread plugin under Tools - Options -
Plugins);
}
NOTE: I want to believe this is overkill and we'll never need to
consider anything even resembling this route, but experience
makes that hard.
-Wyatt
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: I just had an epiphany. I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: I just had an epiphany. I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery Nice quote, but unfortunately there's no such thing as a perfect programming language or a perfect data format. JSON is dirt simple and popular. However using strict JSON for build configuration prevents users from commenting out sections temporarily, and also rejects text that can be understood by a human but doesn't follow JSON's strict rules. It also becomes very unwieldy when any amount of nesting is involved. Then again, when you start writing data formats that are easier to write for humans, you start getting complicated. IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain. I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 13:32:56 UTC, Kagamin wrote:
On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig
wrote:
That's justified, because SDL fails to not surprise. Curly
brace
syntaxes are not line-delimited not requires backslash line
continuations.
Like JavaScript for example?
You mean its feature where it can work without semicolons?
Yeah, that's a silly feature, but it's not forced on everyone.
I have never hit it in my code.
The reason to search for an additional format is to make it
more convenient and readable for human interaction. XML
wouldn't structurally a bad choice, but is awful because of
it's syntactical overhead.
Aren't people more concerned with writing XML rather than
reading? Syntax makes for easier reading and tedious writing.
And overhead is not really big:
menu: { id: file, value: File }
menu id=file value=File/
It's even shorter!
Yes writing it is what I'm concerned about. If you like XML
though, you're gonna love SDL:)
menu id=file value=File
It's even shorter again!
There's 1 to 1 mapping between SDL and XML, SDL just uses
curly-braces and newlines instead of the angle-brackets.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 12:44:00 UTC, eles wrote: On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery Why to not use a classic? Within C++, there is a much smaller and cleaner language struggling to get out. He meant, of course, D. We knew it all along. This is why dforums needs a like button:)
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler wrote: IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain. I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue. I'm not necessarily arguing that Json is great or flexible. I'm arguing, well maybe arguing is a strong word, i'm positing that something more complicated than Json isn't really needed at this time. I understand the argument that it would be nice for human-friendly constructs to be present in the dub file but is this really a problem dub is facing at the minute? Are lots of devs venting their spleens over not being able to include comments, heredoc strings and such in dub files? The dub registry is gaining traction lets not throw an obstacle in the road now. Also inventing a Frankenstein format that is both a superset of Json and SDL just sounds horrible and just sounds wrong. It's just too much. Your effort would be better directed to something which is an immediate problem. Not re-inventing this particular wheel. Sonke has said Json will always be an option in dub. Which is fantastic because now that dub has reached an official level as the de-facto package manager we need to embrace stability and stop this needless change which has been plaguing D forever. I honestly think Ason should be abandoned as an unneeded solution looking for a problem and something more stable and recognised like Yaml or XML, etc. implemented in future *if needed* and actually if requested by dub's users.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 15:27:25 UTC, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler wrote: IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain. I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue. I'm not necessarily arguing that Json is great or flexible. I'm arguing, well maybe arguing is a strong word, i'm positing that something more complicated than Json isn't really needed at this time. I understand the argument that it would be nice for human-friendly constructs to be present in the dub file but is this really a problem dub is facing at the minute? Yes. dub is most definitely facing this problem at this minute. Are lots of devs venting their spleens over not being able to include comments, heredoc strings and such in dub files? The dub registry is gaining traction lets not throw an obstacle in the road now. heredoc's is a new one, but comments/nesting/trailing commas/unquoted strings, yes, most assuredly yes. Have you not been reading people's concerns about JSON? How could you say that people aren't complaining? Also inventing a Frankenstein format that is both a superset of Json and SDL just sounds horrible and just sounds wrong. It's just too much. Your effort would be better directed to something which is an immediate problem. Not re-inventing this particular wheel. I most definitely wouldn't call ASON a Frankenstein format. I didn't design ASON to be a superset of SDL, that's just how it worked out. Just like YAML happens to be a superset of JSON. Instead of saying it sounds horrible and just sounds wrong, why don't you look at the language spec and say what is wrong about it. It's fine if you think we shouldn't use a new language but even if no one ever uses it, it's helpful to know what features people think are good/bad so we can all learn something. Sonke has said Json will always be an option in dub. Which is fantastic because now that dub has reached an official level as the de-facto package manager we need to embrace stability and stop this needless change which has been plaguing D forever. Yes, JSON will always be used to represent the package format on the back-end. So it makes sense to allow users to use it on the front-end if they wish. And again, adding a new format isn't a needless change, why do you think so many people have such strong opinions about what format to use. You seem to be one of the only ones that thinks adding a new format (or using lenient JSON) is a bad thing. I honestly think Ason should be abandoned as an unneeded solution looking for a problem and something more stable and recognised like Yaml or XML, etc. implemented in future *if needed* and actually if requested by dub's users. You seem to be stuck on the idea that I think DUB should use ASON. I created this thread so I could learn from other people what they think about this format and others. Even though you haven't added anything helpful, after reading other people's posts I'm now leaning more towards SDl. My biggest complaint is that it might be confusing for people to go between the SDL version and the JSON version. However, Sonke thinks that he can make a much more friendly package format with SDL's extra features like tag values/attributes.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/26/14, 12:37 PM, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. Now on reddit: http://www.reddit.com/r/programming/comments/2eohiv/microsoft_filed_patent_applications_for_scoped Two links of interest you may want to contribute to: https://patents.stackexchange.com/questions/10128/prior-art-for-us-patent-application-20140196008-immutable-object-types https://patents.stackexchange.com/questions/10122/looking-for-prior-art-for-patent-application-us20140196015-declaration-of-lifet Andrei
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 15:57:41 UTC, Jonathan Marler wrote: Even though you haven't added anything helpful... If you don't want input, don't publicly ask for it. Just because my input is not what you would deem helpful because it contradicts your view does not mean it's of no value. I always argue from a standpoint of zero change regarding anything to do with D and always will do. D and its tools are crying out for stability right now. Change for change sake has seriously hurt D in the past. Yes. dub is most definitely facing this problem at this minute. Where? in this *one* thread?
Re: Before we implement SDL package format for DUB
On Wed, 27 Aug 2014 16:57:52 + Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote: D and its tools are crying out for stability right now. there is D1. stable as a doornail. signature.asc Description: PGP signature
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky
wrote:
On 8/25/2014 6:14 PM, Idan Arye wrote:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler
wrote:
Hello everyone,
I've been working on SDL support for DUB and wanted to get
some
people's opinions on whether we should really use SDL. I've
posted my
thoughts here:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
You said that The standard way to read a dub package
description is to
use the output of dub describe, not to parse dub.json
directly, but
what about tools that *write* to dub.json?
...They *continue* writing to dub.json just as before?
I don't see the problem. dub describe isn't going to
magically start failing just because it was a machine that
wrote to dub.json instead of a human.
You did catch the part where people keep saying that support
for JSON is *not going anywhere*, right?
Currently, if an IDE wants to
use DUB behind the scenes as it's build system it can parse
dub.json and
modify it as it wishes, and that should even work if someone
modified
dub.json by hand. But what if someone modifies dub.json by
hand and adds
ASON stuff to it?
Again, use dub describe to read the data, then write to
dub.{whatever}.
I think we need a command like `dub normalize` that'll
dub describe
convert the dub.json file into a pure JSON file
dub describe
that has exactly the
same data, so IDEs could call it before loading dub.json.
I don't see the problem.
`dub describe` does not give you a normalized version of
dub.json. It gives you something else:
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined -
expected string.
Sure, the data to build a new dub.json is in there - after all,
all the data DUB can provide is in there. But that's the problem
- *all* the data DUB can provide is in there. That includes data
from downloaded dependencies, system data, (possibly) local
configuration data and anything can be added in the future.
That's the point of `dub describe` - query for anything DUB can
tell you and let the user pick what they need.
Even if the result of `dub describe` were valid for dub.json,
you wouldn't want to put all that data in the project's
build-file! You want to be able to put dub.json under source
control and for that it must only contain information about the
project - not about the specific configuration of the machine of
the last developer who happened to run `dub describe` and
overwrite dub.json.
`dub describe` is perfect for automated tools that want to query
DUB, but it's not a solution for tools that need to modify it.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/26/2014 12:37 PM, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. The first release of D 2.000 in 2007 had transitive immutable types in it.
Re: Before we implement SDL package format for DUB
On 8/27/2014 2:38 PM, Idan Arye wrote:
On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky wrote:
On 8/25/2014 6:14 PM, Idan Arye wrote:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:
Hello everyone,
I've been working on SDL support for DUB and wanted to get some
people's opinions on whether we should really use SDL. I've posted my
thoughts here:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
You said that The standard way to read a dub package description is to
use the output of dub describe, not to parse dub.json directly, but
what about tools that *write* to dub.json?
...They *continue* writing to dub.json just as before?
I don't see the problem. dub describe isn't going to magically start
failing just because it was a machine that wrote to dub.json instead
of a human.
You did catch the part where people keep saying that support for JSON
is *not going anywhere*, right?
Currently, if an IDE wants to
use DUB behind the scenes as it's build system it can parse dub.json and
modify it as it wishes, and that should even work if someone modified
dub.json by hand. But what if someone modifies dub.json by hand and adds
ASON stuff to it?
Again, use dub describe to read the data, then write to
dub.{whatever}.
I think we need a command like `dub normalize` that'll
dub describe
convert the dub.json file into a pure JSON file
dub describe
that has exactly the
same data, so IDEs could call it before loading dub.json.
I don't see the problem.
`dub describe` does not give you a normalized version of dub.json. It
gives you something else:
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined - expected
string.
Ok, I see now. Yea, that could be improved. Luckily it shouldn't be a
difficult feature to add, though.
`dub describe` is perfect for automated tools that want to query DUB,
but it's not a solution for tools that need to modify it.
Well, it would probably work, it just wouldn't be an ideal solution. But
again, that dub normalize you suggest (or dub describe --normalize
or something) should do the trick. So it doesn't appear to be a
deal-breaker for supporting another language, it's just an additional
TODO for dub.
Re: Before we implement SDL package format for DUB
On Wednesday, 27 August 2014 at 19:06:29 UTC, Nick Sabalausky
wrote:
On 8/27/2014 2:38 PM, Idan Arye wrote:
On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky
wrote:
On 8/25/2014 6:14 PM, Idan Arye wrote:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler
wrote:
Hello everyone,
I've been working on SDL support for DUB and wanted to get
some
people's opinions on whether we should really use SDL.
I've posted my
thoughts here:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
You said that The standard way to read a dub package
description is to
use the output of dub describe, not to parse dub.json
directly, but
what about tools that *write* to dub.json?
...They *continue* writing to dub.json just as before?
I don't see the problem. dub describe isn't going to
magically start
failing just because it was a machine that wrote to dub.json
instead
of a human.
You did catch the part where people keep saying that support
for JSON
is *not going anywhere*, right?
Currently, if an IDE wants to
use DUB behind the scenes as it's build system it can parse
dub.json and
modify it as it wishes, and that should even work if someone
modified
dub.json by hand. But what if someone modifies dub.json by
hand and adds
ASON stuff to it?
Again, use dub describe to read the data, then write to
dub.{whatever}.
I think we need a command like `dub normalize` that'll
dub describe
convert the dub.json file into a pure JSON file
dub describe
that has exactly the
same data, so IDEs could call it before loading dub.json.
I don't see the problem.
`dub describe` does not give you a normalized version of
dub.json. It
gives you something else:
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined
- expected
string.
Ok, I see now. Yea, that could be improved. Luckily it
shouldn't be a difficult feature to add, though.
`dub describe` is perfect for automated tools that want to
query DUB,
but it's not a solution for tools that need to modify it.
Well, it would probably work, it just wouldn't be an ideal
solution. But again, that dub normalize you suggest (or dub
describe --normalize or something) should do the trick. So it
doesn't appear to be a deal-breaker for supporting another
language, it's just an additional TODO for dub.
I don't like `dub describe --normalize` - it implies that the
regular `dub describe` is in some non-normalize format and adding
this flag will normalize the output. If you want to add
normalization as a `dub describe` flag, I'd prefer something like
`dub describe --buildfile-only`
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wed, Aug 27, 2014 at 11:59:12AM -0700, Walter Bright via Digitalmars-d wrote: On 8/26/2014 12:37 PM, Max Klyga wrote: Microsoft being microsoft again. http://www.freepatentsonline.com/y2014/0196015.html - DECLARATION OF LIFETIME OF RESOURCE REFERENCE This contains description of scoped classes, etc. http://www.freepatentsonline.com/y2014/0196008.html - IMMUTABLE OBJECT TYPES I really hope patent office will reject these applications. The first release of D 2.000 in 2007 had transitive immutable types in it. Since you're the inventor of D, perhaps it would be best if you could submit a prior art submission to the patent office? (Somebody has already posted links earlier in this thread where you can submit it to them directly.) T -- May you live all the days of your life. -- Jonathan Swift
Re: RFC: scope and borrowing
On Tuesday, 26 August 2014 at 22:53:30 UTC, Marco Leise wrote: You could try to formalize some error messages and how the compiler's reasoning would go. What happens when I pass identifiers to scope!(…) return types? - Can the compiler look up the identifiers' types and scopes in all cases? It has to be able to. If a non-visible identifier is specified, it is an error. - Will the compiler deduce the return type from these identifiers? E.g. scope!(someString) ref getString(); will work like in your example? I don't think so, because the lifetime identifiers could be structs containing the returned type. I see, this was a stupid mistake. Of course this function needs to specify the full type, as no type deduction can happen when the body isn't available. Fixed in on the Wiki. - What if we used incompatible types like scope!(someString, someIntPtr) there? - What about variables? Just to be sure: You can only specify variables as owners, not types. I've clarified this on the Wiki. static int someInt = 32; string someString; scope!(someString, someInt) int* x; x = someInt; Is the declaration of x in error? Strings don't contain integers unless unsafe casts are used, so why would they narrow the lifetime of an integer reference? This is an interesting thought... But I would still allow this for a different reason. At the beginning, I only thought about `scope` as a tool for memory management, but I believe it can be applied for lifetime management of arbitrary resources. Let's slightly modify your example, and use different types: Task someProcess; scope!someProcess HANDLE my_handle; `someProcess` could represent an external process that is managed by this program, and `my_handle` could refer to some kind of object in this external process. This handle is only valid as long as the process exists, even though it is not a memory reference, and `Task` might not contain any members of type `HANDLE`. (This is not an ideal example, of course, because the process could terminate for reasons outside of our control.) A similar example would be a connection to the X server, and a handle to an object allocated from it. I already wrote this idea into the section scope for non-reference types, with a simpler example. In fact, I believe that the entire proposal will be a bit simpler if references/pointers aren't treated specially. - Is it necessary to keep around all declared lifetime identifiers? In the snippet above (assuming it is valid), it looks like the shorter lived `someString' is enough to establish the semantics. Yes, it's possible to some degree, see the section Considerations for the implementation. Unfortunately, this doesn't work with function declarations, and is incompatible with the suggested `scope!(const ...)` extension.
Re: Before we implement SDL package format for DUB
On 8/27/2014 5:27 AM, Sönke Ludwig wrote:
Am 27.08.2014 10:02, schrieb Kagamin:
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:
That's somewhat misleading.
More accurately, SDL is newline-delimited (with backslash line
continuation). That's pretty darn simple and has an age-old history.
It's not like we're talking weird Python/JavaScript rules or anything
here.
The only thing that does trip people up is that the existence of { and
} in the syntax makes people think C-family and therefore freeform.
And then it isn't, so that makes them angry. Yeeargh! Hulk Not Want!
Well...or something vaguely sorta kinda like that ;)
That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line
continuations.
Yea, I'll grant it *is* somewhat of a blemish in SDL's design. But I
don't think it's a critical one.
Besides, this thread's (dare I say bikeshedded?) quest for an ideal
data language seems doomed from the start: If we try to avoid the less
common ones, and avoid inventing our own (which I think we have good
reason to avoid), then everything left *does* have imperfections.
Therefore, I think the main critera we should be looking at here, for
any of the possibilities, isn't Does this language have flaws? but
rather Is this language *good enough* to be supported by DUB as a JSON
alternative?
Like JavaScript for example?
Heh, there is that.
What's wrong with XML? I work with it daily and see no problem. The less
syntax a language has, the worse it scales, and if it doesn't scale, its
adoption creates a technical debt. 100 lines with 3 levels of nesting
and JSON becomes hard to follow and TOML becomes simply unmanageable.
The reason to search for an additional format is to make it more
convenient and readable for human interaction. XML wouldn't structurally
a bad choice, but is awful because of it's syntactical overhead.
That's a big one. *The* big one in my mind.
Additionally, despite XML's simplistic appearance, some of the details
about it get disturbingly over-engineered. Heck, take a look at W3C's
docs on it: for something that's *supposed* to be as simple as:
tag1
tag2 attr=valueblah/tag2
tag3 /
/tag1
For something that *appears* to be that simple, it's formal reality is
horrifically complicated.
Besides, there's nothing stopping a good editor from taking this:
{
tag1 : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
}
}
And adding helper visuals (not part of the actual document) to display
it as this:
{
tag1 : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
} itag1/i
} i{root}/i
(The i/i wouldn't be displayed, I just put them there to indicate
the text inside would be visually distinguished so that the user finds
it obvious it's not actually part of the document. Can't really emulate
that in a NG post.)
I don't know why no editors ever do that.
Re: Before we implement SDL package format for DUB
On 8/27/2014 12:57 PM, Gary Willoughby wrote: D and its tools are crying out for stability right now. Change for change sake has seriously hurt D in the past. It's also been a critical factor in it's success. Double-edged sword, admittedly.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/26/2014 2:30 PM, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 Well, I attempted to make a filing of prior art. The application form requires an application number and a patent number. I can't find the patent number, and the form rejects my filing. https://efs.uspto.gov/EFSWebUIUnregistered/EFSWebUnregistered?ActionString=go.Begin
Re: Before we implement SDL package format for DUB
On 8/27/2014 3:26 PM, Idan Arye wrote: I don't like `dub describe --normalize` - it implies that the regular `dub describe` is in some non-normalize format and adding this flag will normalize the output. If you want to add normalization as a `dub describe` flag, I'd prefer something like `dub describe --buildfile-only` Yea, that's better. I just meant Maybe a flag for 'describe' rather than a separate dub command. and didn't feel like coming up with an alternative name. :)
Bug or what?
Ok so me and one of my colleagues have been working on some code
at a distance. We both use dmd as the compiler. I am under
Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
Re: How do I translate this bit of code from C(using pointers) to D?
On Tuesday, 26 August 2014 at 21:29:04 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Tue, Aug 26, 2014 at 08:58:13PM +, MacAsm via
Digitalmars-d wrote:
It maybe trivial to most of you but I don't know how do this
avoiding
string duplications. Can someone help me?
[...]
in D, I can wrote as following:
[...]
void move(int n)
{
prev = str; // - I want to avoid this string duplication
did in every move() call
This does not duplicate the string. You may find this article
helpful:
http://dlang.org/d-array-article.html
Thanks. This is exactly what I was worried about. If no string
duplciation is done I think this D code is just fine...
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 19:35:38 UTC, Walter Bright wrote: On 8/26/2014 2:30 PM, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 Well, I attempted to make a filing of prior art. The application form requires an application number and a patent number. I can't find the patent number, and the form rejects my filing. https://efs.uspto.gov/EFSWebUIUnregistered/EFSWebUnregistered?ActionString=go.Begin There is a number in the patents' page at http://www.freepatentsonline.com labeld under Document Type and Number: Title: DECLARATION OF LIFETIME OF RESOURCE REFERENCE Document Type and Number: United States Patent Application 20140196015 Title: IMMUTABLE OBJECT TYPES Document Type and Number: United States Patent Application 20140196008 Aren't these the patent numbers?
Re: Bug or what?
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am under
Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
size_t is different on 32-bit and 64-bit systems. If she's
building 64-bit binaries on OS-X and you're building 32-bit
binaries on Windows you could see different messages.
Either way, size_t is unsigned, int is signed, and you should
probably be getting the warning as well.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Walter Bright wrote: On 8/26/2014 2:30 PM, Brad Anderson wrote: On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? Does the patent office accept prior art submissions? T They do. http://meta.patents.stackexchange.com/a/107 Well, I attempted to make a filing of prior art. The application form requires an application number and a patent number. I can't find the patent number, and the form rejects my filing. https://efs.uspto.gov/EFSWebUIUnregistered/EFSWebUnregistered?ActionString=go.Begin The patent number is the one in the Document type and number field, where it says United States Patent Application (even though it says application in the text) and the application number is the one in the Application number field. So for patent number 20140196015, the application number is 13/734762 and for patent number 20140196008, the application number is 13/734750. Jerome
Re: Bug or what?
On Wednesday, 27 August 2014 at 19:56:29 UTC, Brian Schott wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
size_t is different on 32-bit and 64-bit systems. If she's
building 64-bit binaries on OS-X and you're building 32-bit
binaries on Windows you could see different messages.
Either way, size_t is unsigned, int is signed, and you should
probably be getting the warning as well.
All right thanks Brian you were right on point.
I 32 she 64.
Indeed, I should have gotten a a warning because it is unsafe.
When I emit code for 64 bit machine I get the error messages she
does, which at least allows me to avoid making her compilation
fail.
Thanks again Brian!
Phil
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Note however that as I understand it D does not have immutable types as claimed by patent 20140196008. The difference is that according to the patent the immutable attribute is given to the type and applies to all instances of this type, whereas in D the immutable attribute applies to an instance (I may be wrong about that one, since I haven't done anything in D for years even if I try to keep up with the forums). However, scala case classes should constitute prior art for this patent. Jerome
Re: Bug or what?
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am under
Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
size_t is a typedef to unsigned (check out
http://dlang.org/type.html). So this warning is correct. I don't
get this warning too. Maybe it's the type-checking that does
differ on OSX. Are you using same compiler version and flags?
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wednesday, 27 August 2014 at 20:08:45 UTC, Jérôme M. Berger wrote: Note however that as I understand it D does not have immutable types as claimed by patent 20140196008. The difference is that according to the patent the immutable attribute is given to the type and applies to all instances of this type, whereas in D the immutable attribute applies to an instance (I may be wrong about that one, since I haven't done anything in D for years even if I try to keep up with the forums). However, scala case classes should constitute prior art for this patent. Jerome In D it applies to type. When you apply immutable to the instance you in fact create new type on the fly by adding immutable qualifier to the existing one. But it can also be aliased to always be immutable.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 5:20 AM, Chris wrote: On Wednesday, 27 August 2014 at 03:00:26 UTC, Nick Sabalausky wrote: Nice. I've heard that a lot of the scenery is stunning over there, too. Slow and expensive electronics importing AIUI, but maybe that'd be in my best interest anyway...biggest thing to raise my blood pressure lately was my last trip to MicroCenter[1]. Take it easy. The most important things are the ideas and the software. The latests gadgets are for users :-) Unfortunately I need to use those gadgets in order to write software on/for them. :/ Heh, man, all I wanted was to find a reasonable inexpensive laptop, that won't choke on Linux, and be certain VT-x was supported in the big three: CPU, mainboard and BIOS. (And the CPU I was looking at supports VT-d too, so I was curious to see if it was actually *usable*, ie not blocked by lack of support in mainboard/BIOS, 'cause that could influence my choice of exact model.) Back in the 90's that all would have been trivial: Slap CPUID (or some 90's equivalent thereof) onto the machine and run it. Heck, published specs used to be detailed and, well, somewhat less unreliable. But these days everyone's so afraid of their own shadow, they've got everything locked down so tightly that the demo units may as well be cardboard props. And expecting published spec to be both complete and accurate? Pfft. No buzzwords == hide the info. And then there's having to hear all of the dumb things coming out of the sales monkeys mouths. Like the password-protected windows admin account being referred to as a firewall. Or the word cloud used for freaking *everything* (with no utterance of the *real* word: Internet). And *all* the verbal nonsense always coming with a heavy dose of suited-smugness and self-assuredness. 'Course, I blame portlandian silicon valley for that whole cloud bs. But whatever. And then there's all the glare-magnet fingerprinted glossy half-height screens, DRM and lockouts to deal with even *after* you buy it, basic-yet-still-missing features that some suit decided I don't need because it saves twenty cents, etc, etc...Ugh. Computing used to be fun. Now it's just corporate paranoia, warring and idiocy. And that's just *real* computers, I haven't even mentioned phones... As soon as I finally snap and go all luddite hermit or something, maybe that's where I'll retire ;) New Zealand that is, not MicroCenter. Swapping your chip for sheep. Sheep are fuzzy!! And tasty! I like! :)
Re: Bug or what?
On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about implicit
casting of uint to int. I'm just wondering... has anybody else
experienced that and what is the expected behavior?
Thanks,
Phil
size_t is a typedef to unsigned (check out
http://dlang.org/type.html). So this warning is correct. I
don't get this warning too. Maybe it's the type-checking that
does differ on OSX. Are you using same compiler version and
flags?
Yeah yeah I checked it out and we both use same versions and
everything. Basically, to bit word size coherent I should just
have writtent this instead:
ptrdiff_t func(size_t i) {return i;}
Though it is still somewhat unsafe, at least it behaves the same
on both our machines.
Phil
Re: Bug or what?
On Wednesday, 27 August 2014 at 20:28:11 UTC, Phil Lavoie wrote:
On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie
wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon that she experiences more strictness in
the type system than I do. For example, something like this
does compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about
implicit casting of uint to int. I'm just wondering... has
anybody else experienced that and what is the expected
behavior?
Thanks,
Phil
size_t is a typedef to unsigned (check out
http://dlang.org/type.html). So this warning is correct. I
don't get this warning too. Maybe it's the type-checking that
does differ on OSX. Are you using same compiler version and
flags?
Yeah yeah I checked it out and we both use same versions and
everything. Basically, to bit word size coherent I should just
have writtent this instead:
ptrdiff_t func(size_t i) {return i;}
Though it is still somewhat unsafe, at least it behaves the
same on both our machines.
Phil
Note that the compiler behaves the same, the code, not
necessarily.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 12:50 PM, Idan Arye wrote: Aren't these the patent numbers? Nope. Too many digits. Tried them, the form rejected them.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 1:17 PM, Dicebot wrote: On Wednesday, 27 August 2014 at 20:08:45 UTC, Jérôme M. Berger wrote: Note however that as I understand it D does not have immutable types as claimed by patent 20140196008. The difference is that according to the patent the immutable attribute is given to the type and applies to all instances of this type, whereas in D the immutable attribute applies to an instance (I may be wrong about that one, since I haven't done anything in D for years even if I try to keep up with the forums). However, scala case classes should constitute prior art for this patent. Jerome In D it applies to type. When you apply immutable to the instance you in fact create new type on the fly by adding immutable qualifier to the existing one. But it can also be aliased to always be immutable. Right. immutable(T) declares a transitive immutable type.
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 1:02 PM, Jérôme M. Berger wrote: So for patent number 20140196015, the application number is 13/734762 and for patent number 20140196008, the application number is 13/734750. Jerome Required fields (Patent Number) cannot be empty or the data entered is incorrectly formatted. The field contains over 9 characters which cannot be processed in the USPTO system.
Re: Before we implement SDL package format for DUB
On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: Therefore, I think the main critera we should be looking at here, for any of the possibilities, isn't Does this language have flaws? but rather Is this language *good enough* to be supported by DUB as a JSON alternative? The 'alternative' bit is the kicker. Personally, I don't believe DUB can succeed at having multiple supported config languages - one or the other will win out over time, and users will diverge. So no language would meet that bar (in my opinion). Mostly we are talking about JSON+stuff as an additional language... so can it be reframed as 'additional features you can use in your dub config file, that aren't strict JSON'? Framing things this way, you could (for example) switch DUB entirely over to ASON, and avoid the 'switching to a new language' arguments. DUB takes JSON, DUB also accepts not-strictly-JSON syntax like comments, etc.
Re: RFC: std.json sucessor
On 8/26/2014 12:24 AM, Don wrote: On Monday, 25 August 2014 at 23:29:21 UTC, Walter Bright wrote: On 8/25/2014 4:15 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright wrote: I didn't know that. But recall I did implement it in DMC++, and it turned out to simply not be useful. I'd be surprised if the new C++ support for it does anything worthwhile. Well, one should initialize with signaling NaN. Then you get an exception if you try to compute using uninitialized values. That's the theory. The practice doesn't work out so well. To be more concrete: Processors from AMD have signalling NaN behaviour which is different from processors from Intel. And the situation is worst on most other architectures. It's a lost cause, I think. The other issues were just when the snan = qnan conversion took place. This is quite unclear given the extensive constant folding, CTFE, etc., that D does. It was also affected by how dmd generates code. Some code gen on floating point doesn't need the FPU, such as toggling the sign bit. But then what happens with snan = qnan? The whole thing is an undefined, unmanageable mess.
Re: Bug or what?
Am Wed, 27 Aug 2014 20:30:08 +
schrieb Phil Lavoie maidenp...@hotmail.com:
On Wednesday, 27 August 2014 at 20:28:11 UTC, Phil Lavoie wrote:
On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie
wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon that she experiences more strictness in
the type system than I do. For example, something like this
does compile for me, but not for her:
int func(size_t i)
{
return i;
}
It passes my compilation. She gets an error msg about
implicit casting of uint to int. I'm just wondering... has
anybody else experienced that and what is the expected
behavior?
Thanks,
Phil
size_t is a typedef to unsigned (check out
http://dlang.org/type.html). So this warning is correct. I
don't get this warning too. Maybe it's the type-checking that
does differ on OSX. Are you using same compiler version and
flags?
Yeah yeah I checked it out and we both use same versions and
everything. Basically, to bit word size coherent I should just
have writtent this instead:
ptrdiff_t func(size_t i) {return i;}
Though it is still somewhat unsafe, at least it behaves the
same on both our machines.
Phil
Note that the compiler behaves the same, the code, not
necessarily.
In my opinion this should always give you a compiler warning,
as it is not portable to 64-bit:
uint func(size_t i) {return i;}
But that has been discussed and reported to death already :D
I'm also somewhat pedantic about assigning unsigned to signed
types and vice versa. Most of the times I'd rather change the
code so that I can keep using e.g. unsigned absolute values
instead of differences.
--
Marco
SWIG?
SWIG has D support. But it seems old and out of fashion. Community here does not buzz about it much either. Whats the word on the street about the quality of SWIG-D stuff? Scott PS thankyou Walter for replying
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Walter Bright newshou...@digitalmars.com Wrote in message: On 8/27/2014 12:50 PM, Idan Arye wrote: Aren't these the patent numbers? Nope. Too many digits. Tried them, the form rejected them. Application number : 13/734750 Patent number: 0196008 --
Re: SWIG?
I've used it quite a bit for a number of bindings (opencv, sfml + many other libs). It's much easier than the conventional approach of manual bindings (eg deimos), especially to keep the port up to date with upstream changes. However the following should be worked on: * support for newly introduced C++ namespaces ( https://github.com/swig/swig/issues/213) * some support for multiple inheritance (I proposed using alias this in https://github.com/swig/swig/issues/98) * mapping of C++ templates to D templates in simple cases at least (the templates would have to be instantiated somewhere in source file of course to avoid linker errors). Only the function signature would be mapped, the implementation would be still on C++ side * miscellaneous compiler warnings that shouldn't be hard to deal with - Deprecation: Read-modify-write operations are not allowed for shared variables : has a pull request (https://github.com/swig/swig/issues/203 ) - missing override * it would help to have a dedicated bug tracker for D-swig. Currently github issues for swig lump all other languages together, making D-swig of limited visibility for D community. At least create a SWIG-D label in github issues. @klickverbot will tell you more as he implemented most of it IIRC On Wed, Aug 27, 2014 at 6:08 PM, Scott Wilson via Digitalmars-d digitalmars-d@puremagic.com wrote: SWIG has D support. But it seems old and out of fashion. Community here does not buzz about it much either. Whats the word on the street about the quality of SWIG-D stuff? Scott PS thankyou Walter for replying
Re: SWIG?
On Thursday, 28 August 2014 at 01:08:43 UTC, Scott Wilson wrote:
SWIG has D support. But it seems old and out of fashion.
Community here does not buzz about it much either. Whats the
word on the street about the quality of SWIG-D stuff?
Scott
PS thankyou Walter for replying
The swig bindings are good and I use them quite a bit to
interface with legacy C++ projects.
This might be fixed already, I don't know and haven't tracked it
but I had to make a minor change to the binding generator, as
shown below.
edit commoncore_im.d and change the following:
---
mixin template SwigOperatorDefinitions() {
...
static if (is(typeof(swigOpEquals(rhs {
return swigOpEquals(rhs);
} else {
...
---
to
---
mixin template SwigOperatorDefinitions() {
...
static if (is(typeof(swigOpEquals(rhs {
return cast(bool)(swigOpEquals(rhs)); // -- cast(bool)
added
} else {
...
---
cheers, uri
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Walter Bright newshou...@digitalmars.com Wrote in message: On 8/27/2014 12:50 PM, Idan Arye wrote: Aren't these the patent numbers? Nope. Too many digits. Tried them, the form rejected them. Spoke too soon. A patent number has not been issued as far as I can tell. This is listed in the application database. From the USPTO FAQ: Does your database include data on pending patent applications? The database only includes data on Published Applications in accordance with the 18 month pre-grant publication rules. Pending patent applications where the applicant has elected to not publish prior to grant remain confidential. --
Re: Before we implement SDL package format for DUB
On 8/27/14, 5:25 AM, Gary Willoughby wrote: On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote: I just had an epiphany. I believe that if I added attributes to ASON, it would be a true superset of SDL. Meaning any SDL file would also be a valid ASON file. What kind of monster did I create! I accidently created a language that serves as both a superset of JSON and SDL? I didn't think that would be possible, expecially with such a little amount of extensions to JSON. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery Then perfection in personal finance is easy to achieve :o). -- Andrei
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On 8/27/2014 8:25 PM, jollie wrote: Walter Bright newshou...@digitalmars.com Wrote in message: On 8/27/2014 12:50 PM, Idan Arye wrote: Aren't these the patent numbers? Nope. Too many digits. Tried them, the form rejected them. Spoke too soon. A patent number has not been issued as far as I can tell. This is listed in the application database. From the USPTO FAQ: Does your database include data on pending patent applications? The database only includes data on Published Applications in accordance with the 18 month pre-grant publication rules. Pending patent applications where the applicant has elected to not publish prior to grant remain confidential. Yeah, and the form rejects all attempts to disclose prior art without a patent number. Reminds me of obamacare.gov :-)
git show previous tag
Anyone here knows how to consistently obtain the previous tag on git? Currently, the installer uses: git describe --abbrev=0 v2.067.0-b1^ This does not always retrieve the correct tag though. In this case the tag prior to v2.067.0-b1 is v2.066.0, however this command returns v2.066.0-b1. This causes a problem because v2.066.0-b1 broke the installer and cannot be used to build DMD. To get around this issue, I usually upload a different version of the compiler in place of v2.066.0-b1. This is not the ideal solution because anyone downloading that v2.066.0-b1.zip will not be getting something completely different. Assistance appreciated. Regards, Andrew
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Wed, Aug 27, 2014 at 09:27:19PM -0700, Walter Bright via Digitalmars-d wrote: On 8/27/2014 8:25 PM, jollie wrote: Walter Bright newshou...@digitalmars.com Wrote in message: On 8/27/2014 12:50 PM, Idan Arye wrote: Aren't these the patent numbers? Nope. Too many digits. Tried them, the form rejected them. Spoke too soon. A patent number has not been issued as far as I can tell. This is listed in the application database. From the USPTO FAQ: Does your database include data on pending patent applications? The database only includes data on Published Applications in accordance with the 18 month pre-grant publication rules. Pending patent applications where the applicant has elected to not publish prior to grant remain confidential. Yeah, and the form rejects all attempts to disclose prior art without a patent number. Reminds me of obamacare.gov :-) Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte ;-) (P.S. Yes, I know the quote has probably been misattributed to Napoleon, but I forgot who the real author is/was since I failed to update my sigs file last time.) T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article Giving it all away
Re: git show previous tag
On 8/27/14, 9:47 PM, Andrew Edwards wrote: Anyone here knows how to consistently obtain the previous tag on git? Are tags always coming in order? Then it's easy: git tag | tail -n2 | head -n1 Andrei
Re: 'idiomatic' porting of c and or c++ code that does NULL checking
On Wednesday, 27 August 2014 at 05:45:34 UTC, eles wrote: While this may be true in this case, I think that, in general, you cannot draw such a clear line between what's recoverable and what's not. If you really want to push things to the extreme, the sole unrecoverable error shall be assertion failure and the SIGKILL. That's exactly the line I would draw. _Nothing_ else is an error, so _everything_ is an exception. Best forget about that something else even exist.
Re: D1: Error: duplicate union initialization for size
On 23/08/14 19:50, jicman wrote:
This is line 7634:
const Size DEFAULT_SCALE = { 5, 13 };
What does the error say and how can I fix it? Thanks.
Does the following make any difference?
const Size DEFAULT_SCAL = Size(5, 13)
--
/Jacob Carlborg
Re: D1: Error: duplicate union initialization for size
On 27/08/14 04:38, jicman wrote: I wish I knew. :-( Above, in this same post I pasted all lines that had Size and right below it all lines that had size. These are all the places where Size is found. If you can tell me which one you think it is, I can grab that piece of the code. I found it, I think. It's declared in drawing.d. Well, at least I found one declared there. But that's not a union, it's a struct. I don't understand why it complains about a struct. -- /Jacob Carlborg
Re: 'idiomatic' porting of c and or c++ code that does NULL checking
On 8/27/2014 2:39 PM, Vladimir Panteleev wrote: On Monday, 25 August 2014 at 03:19:09 UTC, Mike Parker wrote: I use Exception for recoverable errors and Error for those that aren't. Sorry, you're right, that description of Exception/Error is correct. But I don't think that SDL initialization is a non-recoverable error. The program might want to retry SDL initialization with different parameters, and if that code would make it into a library, said library might try using a different graphics library or use some other form of user interaction. It is entirely reasonable for someone to decide that failure to init SDL is an unrecoverable error, while failure to create a window is not, or that both are or neither is. I don't see that any one of the these approaches is set in stone, or that it even need be the same from project to project. The way I structure my code in the little rinky-dink projects scattered about my hard drive, any failure in initializing required systems (like graphics) is an Error, whereas init failure for noncritical systems (like audio) is an Exception. The former I let filter to a top-level handler where I log them and exit, the latter I catch and respond where appropriate. I would very likely take a different approach were I developing a library for public consumption so that the user can decide. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
sdlang-d can not link after updating to dmd 2.066
Hi,
I'm using sdlang-d version 0.8.4
(http://code.dlang.org/packages/sdlang-d).
When I update dmd to version 2.066 today, I found that sdlang-d
won't link, with these errors:
Undefined symbols for architecture x86_64:
_D7sdlang_3ast3Tag103__T11MemberRangeTC7sdlang_3ast3TagVAyaa7_616c6c54616773VAyaa11_746167496e646963696573VAyaa5_5f74616773Z11MemberRange11__invariantMxFZv,
referenced from:
_D7sdlang_3ast3Tag103__T11MemberRangeTC7sdlang_3ast3TagVAyaa7_616c6c54616773VAyaa11_746167496e646963696573VAyaa5_5f74616773Z11MemberRange30__T13opBinaryRightVAyaa2_696eZ13opBinaryRightMFAyaZb
in haha.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
I'm using Mac OSX. Do you have similar issue?
I reduced code to this:
```d
import std.stdio;
import sdlang;
void main()
{
auto cfg = parseFile(hello.sdl);
Tag t = cfg.tags[name][0];
writeln(t);
}
```
I'm wondering sdlang-d needs an update. Or is there a new project
about sdlang?(heard about SDL becoming official in dub, wondering
how dub is parsing SDL).
