Re: DDT 0.7.0 released
On 2013-08-16 15:12, Bruno Medeiros wrote: Very strange! (that it completes the install, but doesn't start properly) Let me see your configuration log, it's at: Help About Eclipse Installation Details Configuration And also the Error log, it's at View Error Log on that same dialog. Here's the log: http://pastebin.com/M6G76Mjv I'm suspecting it doesn't use the correct JRE. I tried to force Eclipse use 1.7 but I doesn't seem to work. -- /Jacob Carlborg
Re: DDT 0.7.0 released
On 19/08/2013 08:40, Jacob Carlborg wrote: On 2013-08-16 15:12, Bruno Medeiros wrote: Very strange! (that it completes the install, but doesn't start properly) Let me see your configuration log, it's at: Help About Eclipse Installation Details Configuration And also the Error log, it's at View Error Log on that same dialog. Here's the log: http://pastebin.com/M6G76Mjv I'm suspecting it doesn't use the correct JRE. I tried to force Eclipse use 1.7 but I doesn't seem to work. It's still using 1.6. You can see it in the log, look for this line: java.runtime.version=1.6.0_51-b11-457-11M4509 -- Bruno Medeiros - Software Engineer
Re: DDT 0.7.0 released
On 16/08/2013 17:26, Russel Winder wrote: On Fri, 2013-08-16 at 14:19 +0100, Bruno Medeiros wrote: […] If you add the update site for the new Eclipse release (for example http://download.eclipse.org/releases/kepler for Kepler) to your current installation, and run the Check for Updates it should update Eclipse and retain all the extra plugins you have installed. (it should update all Eclipse projects that are part of the Kepler release, basically nearly all projects that hosted at Eclipse.org) Having backed everything up (which means creating about 6 replicas for me), I took the plunge and s/4.2/4.3/ s/juno/kepler/ for all my update sites and updated. It appears to have done the needful. Thanks for this, it has saved many hours of swearing. Cool. It would have been amateurish of Eclipse to not have this funcionality, in one way or another. It's a bit annoying that this isn't done automatically in some way, yes. And also annoying that the update site for new releases is not easily found on the Eclipse website either. Bit annoying amounts to a mega-understatement :-) Hum, I guess the annoyance is proportional to the amount of extra plugins you have. Personally I usually only have 1 or 2, the rest comes bundled with Eclipse, but I can definitely see that a lot of users could have a lot more extra plug-ins. -- Bruno Medeiros - Software Engineer
Re: D at University of Minnesota
On Saturday, 17 August 2013 at 15:22:26 UTC, Carl Sturtivant wrote: Well, CS2 in D is over, and grades are in. Being a summer course it was conducted at twice the speed as in a regular semester. [...] http://www.reddit.com/r/programming/comments/1ko94o/experience_report_teaching_d_at_a_summer_course/ Andrei
Re: DDT 0.7.0 released
On Mon, 2013-08-19 at 14:06 +0100, Bruno Medeiros wrote: […] Hum, I guess the annoyance is proportional to the amount of extra plugins you have. Personally I usually only have 1 or 2, the rest comes bundled with Eclipse, but I can definitely see that a lot of users could have a lot more extra plug-ins. CDT, CUTE, Ceylon, Groovy, Gradle, Grails, Dart, TestNG, Go, Android, PyDev, Clojure, JavaScript Not to mention that the default CSS for Eclipse is seriously broken and has to be amended manually. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Lumen - KTextEditor/Kate/KDevelop Autocompletion Plugin
Lumen = Lumen is a KTextEditor autocompletion plugin for the D programming language, which works e.g. in Kate or KDevelop, based on the DCD autocompletion server. Lumen: https://github.com/Dav1dde/lumen DCD: https://github.com/Hackerpilot/DCD With this Plugin KDevelop finally evolves to the most awesome D IDE out there (as DCD improves). You've got autocompletion(, semantic analysis, something I want to add to DCD overtime) and an amazing GDB integration, which works for D out of the be box! Would be great if some of you could test it, it should work flawlessly. TODO (lumen only): * Add include-paths UI * Get rid of dcd-client and implement its functionallity in pure C++ TODO (as DCD progresses): * Best matches, e.g. `void foo(int x);` when completing `foo(` display every local/function which returns an integer in a best matches group * Sorting by inheritance * Sorting by scopes
Re: Lumen - KTextEditor/Kate/KDevelop Autocompletion Plugin
On Monday, 19 August 2013 at 17:59:13 UTC, David wrote: Lumen = Lumen is a KTextEditor autocompletion plugin for the D programming language, which works e.g. in Kate or KDevelop, based on the DCD autocompletion server. Lumen: https://github.com/Dav1dde/lumen DCD: https://github.com/Hackerpilot/DCD With this Plugin KDevelop finally evolves to the most awesome D IDE out there (as DCD improves). You've got autocompletion(, semantic analysis, something I want to add to DCD overtime) and an amazing GDB integration, which works for D out of the be box! Would be great if some of you could test it, it should work flawlessly. TODO (lumen only): * Add include-paths UI * Get rid of dcd-client and implement its functionallity in pure C++ TODO (as DCD progresses): * Best matches, e.g. `void foo(int x);` when completing `foo(` display every local/function which returns an integer in a best matches group * Sorting by inheritance * Sorting by scopes This is awesome. I've tried KDevelop recently and good D support might make me consider using it instead of Vim (especially if Vim mode improves further). Is it viable, in longer-term future, to have features similar to what KDevelop can do for C++? (semantic highlighting, esp. the color variation based on similarity of variable names, automatic creation of a stub of a nonexistent function based on a function call, etc.).
Re: blocks with attributes vs inlined lambda
On Monday, 19 August 2013 at 02:33:43 UTC, Kenji Hara wrote: 2013/8/18 monarch_dodra monarchdo...@gmail.com On Tuesday, 18 June 2013 at 07:58:06 UTC, Kenji Hara wrote: Inlining should remove performance penalty. Nobody holds the immediately called lambda, so it should be treated as a 'scope delegate'. For that, we would need to add a section in language spec to support it. Kenji: I've been doing some benchmarks recently: Using an inlined lambda seems to really kill performance, both with or without -inline (tested with both dmd and gdc). However, using a named function, and then immediately calling it, there is 0 performance penalty (both w/ and w/o -inline). Is this a bug? Can it be fixed? Should I file and ER? I opened a new bugzilla issue: http://d.puremagic.com/issues/show_bug.cgi?id=10848 And start working for the compiler and doc fix: https://github.com/D-Programming-Language/dlang.org/pull/372 https://github.com/D-Programming-Language/dmd/pull/2483 Kenji Hara As always, thank you *very* much.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 18 August 2013 at 18:33:05 UTC, Dicebot wrote: ... When people expect to get a performance gain from simply using certain language, it just can't end good. Specially because they tend to do the common fallacy of comparing languages instead of implementations.
[dox] Add 256-bit SIMD types to Vector Extensions chapter of D Programming Language Specification
My mouse is red hot from clicking around Interwebs trying to find how to fix or report documentation issue. If this is not the best place, please direct me to the right one. Current (downloaded today) version of D Programming Language Specification doesn't have 256-bit SIMD types in Vector Extensions chapter as opposed to core.simd library reference, which has them.
Re: [dox] Add 256-bit SIMD types to Vector Extensions chapter of D Programming Language Specification
On 19 August 2013 08:23, Paul Jurczak pauljurc...@yahoo.com wrote: My mouse is red hot from clicking around Interwebs trying to find how to fix or report documentation issue. If this is not the best place, please direct me to the right one. 'Websites' is a component in the bugzilla: http://d.puremagic.com/issues/enter_bug.cgi?product=D 'spec' is also a keyword to tag against bugs reported in bugzilla: http://d.puremagic.com/issues/describekeywords.cgi Documentation source is hosted here: https://github.com/D-Programming-Language/dlang.org Current (downloaded today) version of D Programming Language Specification doesn't have 256-bit SIMD types in Vector Extensions chapter as opposed to core.simd library reference, which has them. Oh... you mean someone wrote a book? -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: [dox] Add 256-bit SIMD types to Vector Extensions chapter of D Programming Language Specification
On Monday, 19 August 2013 at 07:36:42 UTC, Iain Buclaw wrote: [..] Documentation source is hosted here: https://github.com/D-Programming-Language/dlang.org Thanks, I was close, but somehow missed these files. Now I just have to learn the syntax of .dd files. [..] Oh... you mean someone wrote a book? I took it from http://digitalmars.com/d/2.0/dlangspec.mobi and it seems to be generated from Github files you mentioned.
Re: std.serialization: pre-voting review / discussion
On Sunday, 18 August 2013 at 18:26:55 UTC, Dicebot wrote: On Monday, 12 August 2013 at 13:27:45 UTC, Dicebot wrote: Stepping up to act as a Review Manager for Jacob Carlborg std.serialization So as a review manager, I think voting should be delayed until API is ready to address lazy range-based work model. No actual implementation is required but 1) it should be possible to do it later without breaking user code 2) library should not make an assumption about implementation being lazy or eager Can we path current std.xml to add file input/output, not only memory input/output? It can helps to serialize big data arrays directly in file.
Re: [dox] Add 256-bit SIMD types to Vector Extensions chapter of D Programming Language Specification
On Monday, 19 August 2013 at 07:36:42 UTC, Iain Buclaw wrote: [..] Documentation source is hosted here: https://github.com/D-Programming-Language/dlang.org I submitted my first pull request on Github. Is this the way to go about documentation issues, which are pretty straightforward (no lengthy debate needed)?
Missing dmd.conf for FreeBSD in DMD 2.063.2 release
The subject says it all. -- /Jacob Carlborg
Re: [dox] Add 256-bit SIMD types to Vector Extensions chapter of D Programming Language Specification
On 19 August 2013 09:40, Paul Jurczak pauljurc...@yahoo.com wrote: On Monday, 19 August 2013 at 07:36:42 UTC, Iain Buclaw wrote: [..] Documentation source is hosted here: https://github.com/D-Programming-Language/dlang.org I submitted my first pull request on Github. Is this the way to go about documentation issues, which are pretty straightforward (no lengthy debate needed)? Any lengthy debate can be discussed in the pull you raised. I'll ping Andrei for review. :) Thanks for your contribution. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: trusted purity?
I've been struggling with this, so here are my observations: On Monday, 29 April 2013 at 18:31:15 UTC, Walter Bright wrote: On 4/29/2013 3:58 AM, monarch_dodra wrote: Is there *any* way to make a call to a non-pure function in a pure context, if you know you won't violate your own purity? 2. put the impure code in a separate function, take its address, and cast its address to being a pointer to a pure function. (Of course, such a cast should be rejected by @safe code.) This doesn't work with CTFE. I'm currently not seeing how I could make a function that needs to make a trusted pure call work at compile time: The function pointer cast will fail during CTFE, and if I add a if (__ctfe) block without it, then the function will be impure, due to the code inside the if (__ctfe) block. I've yet to solve this problem. 3. Put the code in an extern(C) function, compiled separately as impure, but declared as pure in the client. C functions don't get name mangling, so the compiler won't know it's impure. Unfortunately, this doesn't work with templates. You have to force instantiation by inserting a straight up (dummy) call to the function, but that immediately makes the caller impure... I feel it's a good thing that you'll need to jump through some hoops to do this, otherwise 'pure' would not be very useful. I agree, but these aren't hoops, they're pole vaults. FYI, the problem I'm trying to fix is this one: * uninitializedArray returns an array with un-initialized elements. This, by definition, is not pure, since the value returned is garbage. I'm fixing the function so that it becomes *impure*. * array is implemented in terms of uninitializedArray: Allocate an array, and then fill it. array is pure, since its return is defined. array also works with ctfe. I'm at a deadlock on this one.
My thoughts on D
Hello, Maybe nobody cares, maybe not. I use D for a month now. It is great, the community is great. Really easy to handle it enables to get the productivity it promises. Almost. I used to run c++. I don't even want to look at my codes now. Instead, I run python along with D. D is very powerful. But it suffers in the details. 1) The library is getting wider. Good. But as of now, it is still TOO MUCH in the c++ style, in which you have to go to github to grab some non official libraries. Sometimes it works, sometimes it won't (of course it will compile but not easy to use or error prone - not a good standard for a language) 2) In comparison, when you use Python, everything is under your hand. No real need to go on github or so on to keep working. Everything feels safe. We miss a gathering point. A bit like pip or the deprecated easy-install. 3) Some pages are not documented properly. And, as i am not someone pointing out the problems and hiding when time comes to propose solutions/solve them, I cannot even figure out the way some standard libraries are expected to work. (e.g:json; the json.org might be helpful but, common, we should have it directly here, not traversing the web (exagerated) to find a clue). 4) Even the merge with 4.9 is no help on these points. Gathering people, yes, showing them a path to follow to be able to stick together, double yes. But the latter seems, ATM, a big no. I know many of you are really smart, so just take this mataphorism : Napoleon, even if one of the greatest commander, would have got far if no backed by generals and a great army knowing where it is going. Let's make a courtesy to D : please do not let it be jailed in Elbe island. It only asks to fly. It is definitely not a bad criticism, please do not take it for such platitude. I would like to see D far beyond what it is currently. You made a GREAT job. Now, let the community help. We need batteries included (python-like). Then everyone will like it: compiled-ultra speed + great useful and centralized libraries. English is not my native speaking, please be kind with it :) Thanks, Larry
Re: My thoughts on D
3) Some pages are not documented properly. And, as i am not someone pointing out the problems and hiding when time comes to propose solutions/solve them, I cannot even figure out the way some standard libraries are expected to work. (e.g:json; the json.org might be helpful but, common, we should have it directly here, not traversing the web (exagerated) to find a clue). A point missed here : I was talking about helping to document. - I cannot even figure out the way some standard libraries are expected to work in order to document them consistently
Re: My thoughts on D
On Monday, 19 August 2013 at 10:10:58 UTC, Larry wrote: 1) The library is getting wider. Good. But as of now, it is still TOO MUCH in the c++ style, in which you have to go to github to grab some non official libraries. Sometimes it works, sometimes it won't (of course it will compile but not easy to use or error prone - not a good standard for a language) what library? phobos is standard library and distributed with compiler, so no need to checkout from githud often(in fact it could give u more troubles due to active dmd development), but if you talk about deimos than i must note this is just collection of C bindings(only), not standard library.
Re: My thoughts on D
On Monday, 19 August 2013 at 10:10:58 UTC, Larry wrote: Hello, Maybe nobody cares, maybe not. I use D for a month now. It is great, the community is great. Really easy to handle it enables to get the productivity it promises. Almost. I used to run c++. I don't even want to look at my codes now. Instead, I run python along with D. D is very powerful. But it suffers in the details. 1) The library is getting wider. Good. But as of now, it is still TOO MUCH in the c++ style, in which you have to go to github to grab some non official libraries. Sometimes it works, sometimes it won't (of course it will compile but not easy to use or error prone - not a good standard for a language) 2) In comparison, when you use Python, everything is under your hand. No real need to go on github or so on to keep working. Everything feels safe. We miss a gathering point. A bit like pip or the deprecated easy-install. dub is a D package manager. Depending on your OS, you might have to download *it* from github, but after that you'll have a wide range of tools at your fingertips. http://code.dlang.org/ 3) Some pages are not documented properly. And, as i am not someone pointing out the problems and hiding when time comes to propose solutions/solve them, I cannot even figure out the way some standard libraries are expected to work. (e.g:json; the json.org might be helpful but, common, we should have it directly here, not traversing the web (exagerated) to find a clue). 4) Even the merge with 4.9 is no help on these points. Gathering people, yes, showing them a path to follow to be able to stick together, double yes. But the latter seems, ATM, a big no. I know many of you are really smart, so just take this mataphorism : Napoleon, even if one of the greatest commander, would have got far if no backed by generals and a great army knowing where it is going. Let's make a courtesy to D : please do not let it be jailed in Elbe island. It only asks to fly. It is definitely not a bad criticism, please do not take it for such platitude. I would like to see D far beyond what it is currently. You made a GREAT job. Now, let the community help. We need batteries included (python-like). Then everyone will like it: compiled-ultra speed + great useful and centralized libraries. English is not my native speaking, please be kind with it :) Thanks, Larry
Re: My thoughts on D
On Monday, 19 August 2013 at 10:29:53 UTC, evilrat wrote: On Monday, 19 August 2013 at 10:10:58 UTC, Larry wrote: 1) The library is getting wider. Good. But as of now, it is still TOO MUCH in the c++ style, in which you have to go to github to grab some non official libraries. Sometimes it works, sometimes it won't (of course it will compile but not easy to use or error prone - not a good standard for a language) what library? phobos is standard library and distributed with compiler, so no need to checkout from githud often(in fact it could give u more troubles due to active dmd development), but if you talk about deimos than i must note this is just collection of C bindings(only), not standard library. I was indeed refering to phobos, yes :)
Re: My thoughts on D
I took the example of std.json. Where are the examples to write, read a json file ? http://dlang.org/phobos/std_json.html is absolutely helpless. It is that : details. When it will be fixed, D will really shine.
Re: When compiling multiple source files
On 2013-08-18 17:31, ProgrammingGhost wrote: How does the compiler do static typing of multiple source files? I heard D malloc memory and doesn't free to speed up compilation but I am guessing every instance doesn't compile just one source file? My question is if I have a function in this file and another in a different file what does the compiler do when both files needs to know the definition of another? Also how does it handle modules? From another thing I heard text parsing can be ridiculously fast so there may be no need for a binary representation of each file parsed. Does the D compiler read all source files into memory generate the AST then starts compiling each file? I know there more than one compiler but I wouldn't mind hearing from either or both if they differ. The compiler will start compiling the files passed on the command line. It will read the files asynchronously and then lex, parse build an AST and do semantic analyze. When the semantic analyze is done it will have access to all import declarations. It basically starts the same processes for all these imports, recursively. The reason for waiting until semantic analyze is done because you can have code looking like this: mixin(import foo;); The expansion of the mixin and other similar features are done in the semantic analyze phase. -- /Jacob Carlborg
Re: Component programming
On Monday, 12 August 2013 at 12:28:36 UTC, Jason den Dulk wrote:
On Wednesday, 31 July 2013 at 10:20:57 UTC, Chris wrote:
This is only losely related to D, but I don't fully understand
the separation of component programming and OOP
What the wikipedia entry is saying, in a roundabout way is:
All objects are components, but not all components are objects.
whereas in pure OOP:
All components are objects.
In an OO framwork, the objects are basically components.
It's the other way around. In OOP frameworks, components are
objects, a small but important distinction. If you relax the
insistance on all components being objects, then OOP becomes a
subset of CP (component programming).
Walter's example
(http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321)
void main() {
stdin.byLine(KeepTerminator.yes)// 1
map!(a = a.idup). // 2
array. // 3
sort. // 4
copy( // 5
stdout.lockingTextWriter());// 6
}
This is a design pattern called pipes and filters, or simply,
the pipeline. There appears to be a bit of confusion about
this. Pipelines are a part of CP, but is not the whole of CP.
Pipelines make use of a type of component called a service.
At its simplest, a service is a function, but it could be a
larger construct or even a whole program. Basically a service
takes input, processes it (with a possible side effect) and
gives a response (output).
Often CP is defined as being exclusively about services, while
other definitions include objects and OOP. Functional
programming is exclusively service oriented.
Purists would insist on using either objects or services
exclusively (OOP vs FP), but there is nothing wrong with
working with both.
Back to pipelines. In a pipeline, you have a chain of services
in which the output of one service is given as the input for
the next. In mathematics it is called functional composition.
The pipeline itself is a service in its own right. You can put
together a pipeline of any length as long as the output -
input interfaces are compatible. In Walter's article, he goes
further to make all interfaces the same to make the components
interchangeable, but this is not necessary in general.
Hope this helps to explain a few things.
Regards
Jason
Thanks for the explanation, Jason.
Btw, I got an error message compiling dcal.d with ldmd2
dcal.d(34): Error: no property 'recurrence' for type 'Date'
It compiles with dmd and works.
Re: My thoughts on D
http://dlang.org/phobos/std_json.html is absolutely helpless. It is that : details. Larry has a point here. I suppose the DDoc is better than nothing, but it doesn't give me a clue how to actually use the package. But enough complaining, to improve the documentation would I 1) clone Phobos in github 2) improve the docs on my branch 3) request a (merge|pull|whatever the git verb is to apply my changes) Assuming that path is correct, to whom would I send the request to perform #3? If that path isn't correct how would I go about improving the docs for a part of Phobos? I'm willing to read code and put together examples as long as they are of some general utility. If I'm just doing it by myself for myself it's not worth my time.
Re: Tango Phobos
On Sunday, 2 May 2010 at 18:16:59 UTC, Bane wrote: Walter Bright Wrote: Bane wrote: I meant on topic removal from DM newsgroup. I guess Walther did it, as he is the one administering it, right? I support his decision for a reason I wrote above. Yes, I did it, it was my idea to do so. I did it for the reason you suggest (not the Stalin one!) but the one about letting our hot tempers cool a bit so hopefully we can find the best solution for D, not an ego-driven one. As I said, this Stalin thing is joke on efficiency and speed of action was taken. Comparing Walther to Staling was not my intention.
Re: std.serialization: pre-voting review / discussion
On 2013-08-18 01:31, Jesse Phillips wrote: I'd like to start off by saying I don't really know what I want from a std.serialize module. I've done some work with a C# JSON serializer and dealt with Protocol Buffers. This library looks to be providing a means to serialize any D data structure. It deals with pointers/class/struct/arrays... It is export format agnostic, while currently only XML is available, allowing for export to JSON or some binary form. Afterwards the data can return to the program through deserialization. This is a use-case I don't think I've needed. Though I do see the value in it and would expect Phobos to provide such functionality. What I'm not finding in this library is a way to support a 3rd party protocol. Such as those used in Thrift or Protocol Buffers. These specify some aspects of data layout, for example in Protocol Buffers arrays of primitives can be laid out in two forms [ID][value][ID][value] or [ID][Length][value][value]. I have had a brief look at Protocol Buffers and I don't see why it wouldn't work as an archive. I would probably need to implement a Protocol Buffers archive type to see what the limitations of std.serialization and Protocol Buffers are. Thrift and Protocol Buffers use code generation to create the language data type, and at least for Protocol Buffers a method contains all the logic for deserializing a collection of bytes, and one for serializing. I'm not seeing how std.serialize would make this easier or more usable. If a Thrift or Protocol Buffers archive would be used with std.serialization I'm thinking that one would skip that step and have the data types defined directly in D. When looking at the Archive module, I see that all the specific types get their own void function. I'm unclear on where these functions are supposed to archive to The archive holds the data. When the serialization is complete the data can be accessed using archive.data. , and container types take a delegate which I suppose is a means for the archiver to place output around the field data. Yes, exactly. It lets the archive know where a structured type begins and ends. In conclusion, I don't feel like I've said very much. I don't think std.serialize is applicable to Protocol Buffers or Thrift, and I don't know what benefit there would be if it was. -- /Jacob Carlborg
Re: trusted purity?
monarch_dodra:
FYI, the problem I'm trying to fix is this one:
* uninitializedArray returns an array with un-initialized
elements. This, by definition, is not pure, since the value
returned is garbage. I'm fixing the function so that it becomes
*impure*.
* array is implemented in terms of uninitializedArray:
Allocate an array, and then fill it. array is pure, since its
return is defined. array also works with ctfe.
Here are some examples of what I think you are talking about.
foo1 is pure, foo2 is pure (but currently the type system doesn't
complain), foo3 is pure again because all array items are
deterministically initialized using only pure/immutable data:
// Pure:
int[3] foo1(in int x) pure {
int[3] arr;
return arr;
}
// Not pure:
int[3] foo2(in int x) pure {
int[3] arr = void;
return arr;
}
// Pure:
int[3] foo3(in int x) pure {
int[3] arr = void;
arr[] = x;
return arr;
}
void main() {}
I presume foo2 should be refused as not pure. The array()
function is like foo3, it creates data that is not pure, not
deterministic, but then overwrites it all with referentially
transparent information. So on the whole foo3 is pure and array()
is often pure.
The problem is that while writing down the proof of the purity of
foo3 is probably not too much hard, later the D compiler is not
able to verify such proof. So some alternative solution is
needed. The trusted pure you talk about is a solution, it means
saying to the compiler, trust me I have a proof of purity of
this function. But programmers should be trusted as little as
possible if you want a reliable language and reliable programs.
So perhaps some mid-way solution is preferable.
Andrei used the idea of cooked and uncooked variables, it's
probably used here:
class Bar1 {
immutable int[2] x;
this() {
}
}
Bar1 gives the error:
Error: constructor test.Bar1.this missing initializer for
immutable field x
While this gives no errors:
class Bar2 {
immutable int[2] x;
this() {
x[0] = 1;
}
}
Perhaps using a similar strategy you can accept a function like
this:
int[3] foo3(in int x) pure {
int[3] arr = void;
arr[] = x;
return arr;
}
Because now arr is not uncooked, it was overwritten by
referentially transparent data...
For the function array() this is not enough, because instead of
= void you have a function that returns some void-initialized
data. To help the D type system a bit perhaps an annotations like
@void_init is useful, to be attached to functions like
uninitializedArray and minimallyInitializedArray.
Bye,
bearophile
Re: std.serialization: pre-voting review / discussion
On 2013-08-18 20:26, Dicebot wrote: OK, time to make a short summary. There have been mentioned several issues / improvement possibilities. I don't think they prevent voting and it is up to Jacob to decide what he want to incorporate from it. I've been quite busy lately but I've tried to address the minor issues with regards of documentation. I've hit a new problem in the process: http://forum.dlang.org/thread/kujcns$1quo$1...@digitalmars.com However, there are two things that do matter in my opinion - pre-UDA part of API and uncertainty about range-based lazy approach. Important thing here is that while library can be included with plenty of features lacking we can't really afford to break its API only few releases later just to add/remove these features. What do you mean with pre-UDA part of API? I think it will be fairly easy to add support for ranges, at least for the output. I'll see what I can do. So as a review manager, I think voting should be delayed until API is ready to address lazy range-based work model. No actual implementation is required but 1) it should be possible to do it later without breaking user code 2) library should not make an assumption about implementation being lazy or eager That is my understanding based on current knowledge of Phobos modules, please correct me if I am wrong. Jacob, please tell if you have any objections or, if this decision sounds reasonable - just contact me via e-mail when you will find std.serialization suitable for final voting. I think it is pretty clear that package itself is considered useful and welcome to Phobos. -- /Jacob Carlborg
Re: My thoughts on D
1) The library is getting wider. Good. But as of now, it is still TOO MUCH in the c++ style, in which you have to go to github to grab some non official libraries. Sometimes it works, sometimes it won't (of course it will compile but not easy to use or error prone - not a good standard for a language) You could have two schools of thought about this. Either have a library that includes as much as possible, everything that could be conceivably used. (Called batteries included) Or a smaller library that focusus on the more common stuff that can be reasonably expected to used in most programs. (Called some assembly required) The advantage of the former is that you don't have to hunt as much for lesser used code. The advantage of the latter is that it is easier to maintain and the library maintainers can focus on providing those components well, and have better assurances that what's in the library is of good quality. I don't know what Walter's long term plans are for Phobos, but I personally favour the latter. Also remember that D is still fairly young. It's code base is growing, and I image the library will grow too. Give it time. 2) In comparison, when you use Python, everything is under your hand. No real need to go on github or so on to keep working. Everything feels safe. We miss a gathering point. A bit like pip or the deprecated easy-install. I presume you mean a code repository where libraries are kept and can be downloaded and installed via a special program. One exists for D. Its called dub.
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 12:57:56 UTC, Jacob Carlborg wrote: I've been quite busy lately but I've tried to address the minor issues with regards of documentation. I've hit a new problem in the process: http://forum.dlang.org/thread/kujcns$1quo$1...@digitalmars.com I also expect that enhancement to dlang.org to support package.d documentation will also probably be needed at some point to get proper examples. Such issues can be worked on during actual merge process and are not worth blocking voting. What do you mean with pre-UDA part of API? This thread: http://forum.dlang.org/post/xqklcesoguxujifij...@forum.dlang.org I think it will be fairly easy to add support for ranges, at least for the output. I'll see what I can do. Great! Are there any difficulties with the input?
Re: My thoughts on D
On Monday, 19 August 2013 at 12:03:14 UTC, Jason King wrote: But enough complaining, to improve the documentation would I 1) clone Phobos in github 2) improve the docs on my branch 3) request a (merge|pull|whatever the git verb is to apply my changes) Assuming that path is correct, to whom would I send the request to perform #3? You should just use a normal GitHub pull request vs https://github.com/D-Programming-Language/dlang.org master.
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 12:49:48 UTC, Jacob Carlborg wrote: I have had a brief look at Protocol Buffers and I don't see why it wouldn't work as an archive. I would probably need to implement a Protocol Buffers archive type to see what the limitations of std.serialization and Protocol Buffers are. You can find the Protocol Buffers library here, may be it helps: https://256.makerslocal.org/wiki/index.php/ProtocolBuffer
Re: std.serialization: pre-voting review / discussion
On 2013-08-19 15:03, Dicebot wrote: Great! Are there any difficulties with the input? It just that I don't clearly know how the code will need to look like, and I'm not particular familiar with implementing range based code. -- /Jacob Carlborg
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 13:31:27 UTC, Jacob Carlborg wrote: On 2013-08-19 15:03, Dicebot wrote: Great! Are there any difficulties with the input? It just that I don't clearly know how the code will need to look like, and I'm not particular familiar with implementing range based code. Ok, I'll investigate related part of package a bit more in details during this week and see if I can suggest something.
Re: My thoughts on D
On Monday, 19 August 2013 at 12:03:14 UTC, Jason King wrote: http://dlang.org/phobos/std_json.html is absolutely helpless. It is that : details. Larry has a point here. I suppose the DDoc is better than nothing, but it doesn't give me a clue how to actually use the package. But enough complaining, to improve the documentation would I 1) clone Phobos in github 2) improve the docs on my branch 3) request a (merge|pull|whatever the git verb is to apply my changes) Assuming that path is correct, to whom would I send the request to perform #3? If that path isn't correct how would I go about improving the docs for a part of Phobos? I'm willing to read code and put together examples as long as they are of some general utility. If I'm just doing it by myself for myself it's not worth my time. The wiki has the definite answers. http://wiki.dlang.org/Pull_Requests
Re: ClassInfo.find not working for nested classes
On Thursday, 15 August 2013 at 20:12:44 UTC, Jacob Carlborg wrote: I just noticed that ClassInfo.find not working for nested classes, even if they are static. For example: Bugzilla?
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 13:31:27 UTC, Jacob Carlborg wrote:
On 2013-08-19 15:03, Dicebot wrote:
Great! Are there any difficulties with the input?
It just that I don't clearly know how the code will need to
look like, and I'm not particular familiar with implementing
range based code.
Maybe we need some kind of doc explaining the idiomatic usage of
ranges?
Personally, I'd like to do something like this:
auto archive = new XmlArchive!(char); // create an XML archive
auto serializer = new Serializer(archive); // create the
serializer
serializer.serialize(foo);
pipe(archive.out, someFile);
Where pipe would read from the left and write to the right. My
idea for an implementation is through using take():
void pipe(R) (R input, File output) // isInputRange(R)...
{
while (!input.empty) {
// if Serializer has no data cached, goes through one
step
// and returns what it has
auto arr = input.take(BUF_SIZE);
input.popFrontN(arr.length);
output.write(arr);
}
}
For now, I'd be happy for serializer to process all data in
serialize(), but change the behavior later to do step through
computation when calling take().
I don't know if this helps, and others are very likely to have
better ideas.
Re: windows .lib files (dmc has them, dmd doesn't)
On Sunday, 18 August 2013 at 14:53:25 UTC, Andrej Mitrovic wrote: On Sunday, 18 August 2013 at 14:51:52 UTC, Adam D. Ruppe wrote: Can we get some more .lib files with the dmd distribution? And also update the old ones: http://d.puremagic.com/issues/show_bug.cgi?id=6625 This should really take precedence.
Re: std.serialization: pre-voting review / discussion
On Sunday, 18 August 2013 at 20:33:01 UTC, Jonathan M Davis wrote: On Sunday, August 18, 2013 21:45:59 Jacob Carlborg wrote: If versioning is crucial it can be added. I don't know if it's crucial or not, but I know that the Java guys didn't have it initially but ended up adding it later, which would imply that they ran into problems that made them decide that it should be there. I'd certainly be inclined to think that it's better to have it, and it's probably easier to add it before it's merged than later. But I don't know how crucial it is. - Jonathan M Davis I think this versioning idea is more important for protocol buffers, msgpck, thrift like libraries that use a separate IDL schema and IDL-compiled code. std.serialization uses the D code itself to serialize so the version is practically dictated by the user. It may as well be manually handledas long as it throws/returns error and doesn't crash if one tries to deserialize an archive type into a different/modified D type. From memory the Protocol Buffers versioning is to ensure schema generated code and library are compatible. You get compile errors if you try to compile IDL generated code with a newer version of the library. Similarly you get runtime errors if you deserialize data that was serialized with an older version of the library. This is all from memory so I could be wrong... Orange seems/feels more like the BOOST.serialization to me but much better. It's D for a start and allows custom archive types. In BOOST, the library stores a version number in the archive for each class serialized. This number defaults to 0 but can be set by the user via a #define. http://www.boost.org/doc/libs/1_54_0/libs/serialization/doc/tutorial.html#versioning I think adding it later can be done without breaking existing API, if it is deemed necessary. It just needs to default to 0 or something similar when missing from an archive and ensure it won't clash with any fields in existing archives.
Re: trusted purity?
On Monday, 19 August 2013 at 12:55:54 UTC, bearophile wrote:
The problem is that while writing down the proof of the purity
of foo3 is probably not too much hard, later the D compiler is
not able to verify such proof.
Bye,
bearophile
Right, that is pretty much it. EG:
//
import core.stdc.stdlib;
int* myPureFun(int i) pure
{
auto p = cast(int*) malloc(int.sizeof);
if (!p) assert(0);
*p = i;
return p;
}
//
I can solve this the same way (kind of) as with safety, by
marking the function as I can mark a function as trusted, by
casting the function as pure:
//
int* myPureFun(int i) pure
{
alias extern (C) void* function(size_t) pure PureF_t;
auto p = cast(int*) (cast(PureF_t)malloc)(int.sizeof);
if (!p) assert(0);
*p = i;
return p;
}
//
A basic I know what I'm doing compiler kind of assertion.
My only issue with doing this is I'm afraid it might be wrong: A
trusted function means nothing to the compiler.
However, in the above example, I *marked* malloc as pure, and
even though myPureFun is conceptually pure, *malloc* remains
impure, and I don't know how the compiler deals with being told
it is pure.
Is that code snippet wrong?
Re: std.serialization: pre-voting review / discussion
On 2013-08-19 15:47, Dicebot wrote: Ok, I'll investigate related part of package a bit more in details during this week and see if I can suggest something. What I have now is something like this: auto foo = new Foo; foo.a = 3; auto archive = new XmlArchive!(string); // string is the range type auto serializer = new Serializer(archive); serializer.serialize(foo); auto data = archive.data; // returns a range, typed as XmlArchiveData The problem now is that the range type is string, so I can't set the data using any other range type: archive.data = data; Results in: Error: cannot implicitly convert expression (range) of type XmlArchiveData to string How can I handle that? -- /Jacob Carlborg
Re: ClassInfo.find not working for nested classes
On 2013-08-19 16:10, ilya-stromberg wrote: Bugzilla? Yeah, I was hoping to start a discussion here to see if it's even possible to support. -- /Jacob Carlborg
Re: ClassInfo.find not working for nested classes
On 2013-08-19 16:10, ilya-stromberg wrote: Bugzilla? Added: http://d.puremagic.com/issues/show_bug.cgi?id=10853 -- /Jacob Carlborg
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 13:17:48 UTC, ilya-stromberg wrote: On Monday, 19 August 2013 at 12:49:48 UTC, Jacob Carlborg wrote: I have had a brief look at Protocol Buffers and I don't see why it wouldn't work as an archive. I would probably need to implement a Protocol Buffers archive type to see what the limitations of std.serialization and Protocol Buffers are. You can find the Protocol Buffers library here, may be it helps: https://256.makerslocal.org/wiki/index.php/ProtocolBuffer Code has moved to https://github.com/opticron/ProtocolBuffer
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 12:49:48 UTC, Jacob Carlborg wrote: I have had a brief look at Protocol Buffers and I don't see why it wouldn't work as an archive. I would probably need to implement a Protocol Buffers archive type to see what the limitations of std.serialization and Protocol Buffers are. I not familiar with the interaction of Archive and Serializer. I was overwhelmed by the number of functions I'd have to implement (or in my case ignore) and ultimately I didn't know what my serialized data would look like. I think it is possible to output a binary format which uses the same translation as Protocol Buffers, but I wouldn't expect it to resemble a message. Thrift and Protocol Buffers use code generation to create the language data type, and at least for Protocol Buffers a method contains all the logic for deserializing a collection of bytes, and one for serializing. I'm not seeing how std.serialize would make this easier or more usable. If a Thrift or Protocol Buffers archive would be used with std.serialization I'm thinking that one would skip that step and have the data types defined directly in D. I'll see if I can push my way through creating an Archive type.
Re: Any cryptographically secure pseudo-random number generator (CSPRNG) for D?
On Sunday, 18 August 2013 at 19:32:50 UTC, QAston wrote: You may be interested in https://github.com/D-Programming-Deimos/openssl - D bindings for openssl. How can I get access to the /dev/random or /dev/urandom (Linux only)? Like a file via std.file, or D have spesial function?
Re: Any cryptographically secure pseudo-random number generator (CSPRNG) for D?
On Monday, 19 August 2013 at 15:56:04 UTC, ilya-stromberg wrote: On Sunday, 18 August 2013 at 19:32:50 UTC, QAston wrote: You may be interested in https://github.com/D-Programming-Deimos/openssl - D bindings for openssl. How can I get access to the /dev/random or /dev/urandom (Linux only)? Like a file via std.file, or D have spesial function? I don't know of any special function to access them.
Re: std.serialization: pre-voting review / discussion
On 2013-08-19 17:40, Jesse Phillips wrote: I not familiar with the interaction of Archive and Serializer. I was overwhelmed by the number of functions I'd have to implement (or in my case ignore) and ultimately I didn't know what my serialized data would look like. std.serialization basically support any type in D (except for delegates and function pointers). If a particular method doesn't make sense to implement for a given archive, just implement a dummy function to satisfy the interface. The documentation for Archive says so: When implementing a new archive type, if any of these methods do not make sense for that particular implementation just implement an empty method and return T.init, if the method returns a value. If something breaks due to this please let me know. I think it is possible to output a binary format which uses the same translation as Protocol Buffers, but I wouldn't expect it to resemble a message. In the binary archive I'm working on I have chosen to ignore some parts of the implicit contract between the serializer and the archive. For example, I'm not planning to support slices, pointers to fields and similar complex features. -- /Jacob Carlborg
Re: std.serialization: pre-voting review / discussion
On 2013-08-19 15:03, Dicebot wrote: This thread: http://forum.dlang.org/post/xqklcesoguxujifij...@forum.dlang.org I have removed all uses of mixin annotations. -- /Jacob Carlborg
Re: Actor model D
On 8/18/13 9:24 PM, Tyler Jameson Little wrote: On Monday, 19 August 2013 at 03:11:00 UTC, Luís Marques wrote: Can anyone please explain me what it means for the D language to follow the Actor model, as the relevant Wikipedia page says it does? [1] [1] http://en.wikipedia.org/wiki/Actor_model#Later_Actor_programming_languages I assume this refers to task in std.parallelism and the various bits in std.concurrency for message passing. I'm very surprised that D made the cut but Go didn't. I'm even more surprised that Rust was included even though it's not even 1.0 yet while Go is at 1.1.1 currently. I wish they had some kind of explanation or code examples to justify each one as in other articles, because I'm also very interested... Go is CSP - isn't that different from Actor? Andrei
Re: Language and library reference pages very slow to load
On 8/18/13 10:28 PM, H. S. Teoh wrote: On Mon, Aug 19, 2013 at 06:42:04AM +0200, finalpatch wrote: Apparently the javascript that's responsible for creating hyperlinks runs very slowly, usually several seconds or longer. eg. http://dlang.org/phobos/core_memory.html is so slow it causes Mozilla Firefox to pop up the page not responding box. I have also tried Internet Explorer 10 on Windows 7 and Safari on Mac OS X 10.8.4 and got similar results. I wonder if it's possible to move this to the server side given the documents are mostly static contents. My guess is that this is caused either by hyphenate.js or hyphenate-selectively.js, both of which, thankfully, will be going away once dlang.org is updated (their removal has already been merged into git HEAD). Wasn't JS hyphenation only removed for browsers that support hyphenation at CSS level? Andrei
Re: Language and library reference pages very slow to load
On 8/18/13 9:42 PM, finalpatch wrote: Apparently the javascript that's responsible for creating hyperlinks runs very slowly, usually several seconds or longer. eg. http://dlang.org/phobos/core_memory.html is so slow it causes Mozilla Firefox to pop up the page not responding box. I have also tried Internet Explorer 10 on Windows 7 and Safari on Mac OS X 10.8.4 and got similar results. I wonder if it's possible to move this to the server side given the documents are mostly static contents. I have a pull request on github that should fix that. Andrei
Please submit to bugzilla (Was: Re: Missing dmd.conf for FreeBSD in DMD 2.063.2 release)
On 8/19/13 2:16 AM, Jacob Carlborg wrote: The subject says it all. Ditto :o). Andrei
Re: std.serialization: pre-voting review / discussion
On 2013-08-19 17:41, Jesse Phillips wrote: Code has moved to https://github.com/opticron/ProtocolBuffer Does it have any utility functions that are fairly standalone to handle the basic types, i.e. int, string, float and so on? -- /Jacob Carlborg
Re: Please submit to bugzilla (Was: Re: Missing dmd.conf for FreeBSD in DMD 2.063.2 release)
On 2013-08-19 18:27, Andrei Alexandrescu wrote: Ditto :o). Done: http://d.puremagic.com/issues/show_bug.cgi?id=10855 -- /Jacob Carlborg
64bit version of DMD for FreeBSD in the release?
Is there a reason for why we don't have a 64bit version of DMD for FreeBSD in the release? -- /Jacob Carlborg
Re: Actor model D
On Mon, 2013-08-19 at 09:20 -0700, Andrei Alexandrescu wrote: […] Go is CSP - isn't that different from Actor? CSP certainly is very different from actors, it's in the synchronization structure. Go's model isn't CSP per se, it is a more or less the same thing developed by Pike over the years. At it's coarsest: An actor processes a message from it's message drop as and when it wishes and send messages to other actors it know the message drop for asynchronously. Processes in CSP rendezvous in order to pass messages down a one-to-one channel, which has no buffering. Modern CSP allows one-to-one, one-to-many, many-to-one and many-to-many channels with or without buffering. CSP processes with many-to-one channels with large buffering can appear very like actors. Actors that are effectively event loops can be made to look an awful lot like CSP. The are different but there are shades of grey (no not that sort of activity :-) so it is easy to see how people might get confused. The third player here is dataflow, and this is increasingly used for Big Data and might be worth thinking about in std.parallelism. An operator (a process as in CSP, but the whole model comes from 1970s dataflow computer research hence operator) is event driven. An operator springs into action when a pattern of data-readiness on it's inputs occurs. It them computes and outputs results on it's output channels. We like dataflow. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Actor model D
On Monday, 19 August 2013 at 16:20:37 UTC, Andrei Alexandrescu wrote: Go is CSP - isn't that different from Actor? Andrei I'd be interested to know the difference.
Re: A Discussion of Tuple Syntax
Note: I'm leading off with a reply to bearophile transplanted
here to stop making OT noise in John's thread about TypeTuple.
On Friday, 16 August 2013 at 23:23:59 UTC, bearophile wrote:
It's short, clear, has a precedent with q{}.
Wait, what is q{}? That's something in D? What does that even
do? I can infer that q{} is probably some manner of scoping or
grouping _something_ somehow, but I have to dig into lexical and
manually search for q{ to find out it's [neither of the things I
expected]. In my view, this right here is really just a
fundamental problem with single-character prefixes and I feel
that's something we should endeavour to avoid, if possible.
I don't like it a lot, but it's way better than not having
language support for tuples.
On this, I think we all agree.
I'd prefer just using parentheses, but I think there were
readability problems that caused the DIP to end up with:
More than just readability problems. They were discussed when
Kenji presented the DIP 32 in this forum. Timon found a
significant problem with the {} syntax.
To be clear, I'm not talking about braces, {}; I'm talking about
parentheses, (). I read over that whole DIP32 thread a couple
times, and didn't see any rationale offered for why the likely
cleanest version can't be used. It wasn't even brought up
(unless I've missed something subtle). In the second thread,
linked in the OP here, they were glossed over again. Now, I
fully believe there's a very good reason that's been written
somewhere, but I _would_ like to know what that is, preferably
documented somewhere less ephemeral and difficult to search than
the newsgroup (such as in DIP32). The closest I've seen so far
is the pull request where Walter and Andrei expressed that it
should be considered further.
On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
- #(a, b) is unambiguous and would probably be the easiest
option. I don't think it looks too bad, but some people might
find it ugly and noisy
The octothorpe _is_ much better than the t simply in terms of
readability, though, even more than q{} or t{}, I have concerns
about its ability to be found with an ordinary search engine by
an ordinary user. Have you tried looking for documentation on
weird operators with a search engine lately? They don't exactly
take to it well. :/ (cf. Perl's =)
Addressing the other suggestion I saw that cropped up, I
personally find the two-character bananas to be impressively
ugly. I considered suggesting some permutation on that same
idea, but after toying with a few examples I find it ends up
looking awful and I think it's honestly annoying to type them in
any form. I even don't like how the unicode version of that one
looks; for doubling up, I think ⟦ ⟧ or ⟪ ⟫ or are easier on the
eyes.
It's times like these that I wish the standard PC keyboard had
something like guillemets « », or corner brackets ｢ ｣ (big fan of
these) in addition to everything else. (Or even that we could use
for bracing, though at this point I don't think I could
easily condone that move for D).
I feel weird admitting this, but if we can't use some manner of
bare brace, I think I'd rather have tup(), tup[], tup{} (or even
tuple() et al) as a prefix over any single character.
Another stray thought: is there room for a little box of syntax
chocolate so that e.g. tuple(), [||], and ⟦ ⟧ are all valid? I
don't know if we have a precedent like that off the top of my
head and I'm pretty sure I don't like it, but I thought I'd at
least mention it.
- There was no consensus on the pattern matching syntax for
unpacking. For example, #(a, _) = #(1, 2) only introduces one
binding, a, into the surrounding scope. The question is, what
character should go in the place of _ to signify that a value
should not be bound? Some suggestions were #(a, $), #(a, @),
#(a, ?). I personally think #(a, ?) or #(a, *) would be best,
but all that's really necessary is a symbol that cannot also
be an identifier.
Can't make it a single underscore? Question mark works best then,
IMO. It isn't as burdened with meanings elsewhere (sure there's
ternary and possibly-match in regex, but...have I forgotten
something?)
Also up for debate was nested patterns, e.g., #(1, 2, #(3,
4, #(5, 6))). I don't think there was a consensus on unpacking
and pattern matching for this situation. One idea I saw that
looked good:
Ah, I was wondering about the case of a tuple of tuples. It's
not mentioned in the DIP that I saw, so I assumed it was allowed,
but explicit mention is probably warranted.
* Use ... to pattern match on the tail of an
expressions, so take the above tuple. The pattern #(1, ?, ...)
would match the two nested sub-tuples. Or, say, #(1, 2, 3)
could be matched by #(1, 2, 3), #(1, ?, 3), #(1, ...), etc. You
obviously can't refer to ... as a variable, so it also
becomes a useful way of saying don't care for multiple items,
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 16:53:06 UTC, Wyatt wrote:
Note: I'm leading off with a reply to bearophile transplanted
here to stop making OT noise in John's thread about TypeTuple.
On Friday, 16 August 2013 at 23:23:59 UTC, bearophile wrote:
It's short, clear, has a precedent with q{}.
Wait, what is q{}?
Check Token Strings in http://dlang.org/lex.html
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 16:57:35 UTC, Dicebot wrote: Check Token Strings in http://dlang.org/lex.html Didn't make it to the end of the paragraph? ;)
Re: When compiling multiple source files
On Monday, 19 August 2013 at 11:01:54 UTC, Jacob Carlborg wrote: The compiler will start compiling the files passed on the command line. It will read the files asynchronously and then lex, parse build an AST and do semantic analyze. When the semantic analyze is done it will have access to all import declarations. It basically starts the same processes for all these imports, recursively. The reason for waiting until semantic analyze is done because you can have code looking like this: mixin(import foo;); The expansion of the mixin and other similar features are done in the semantic analyze phase. So everything is parsed once and kept in memory until the compiler finish every source file? Is there any ram problems when compiling large codebases? My experience with D is limited. Are libraries the same as C libraries? From my understanding the linker figures that part out and the compiler needs a separate file for the definition. If I build a library in D is it the same as a C library or different which includes function definitions? Sorry if I'm confused I know almost nothing about D. I stick to .NET, java and C++
Re: A Discussion of Tuple Syntax
On Mon, Aug 19, 2013 at 06:53:05PM +0200, Wyatt wrote: [...] This is the third or fourth time that I know of that tuple syntax has come up, and as of yet, nothing has been done about it. I'd really like to get the ball rolling on this, as I think a good syntax for these tuple operations would do D a world of good. I'm not a compiler hacker, unfortunately, so I can't implement it myself as proof of concept... However, I hope that discussing it and working out all the kinks will help pave the way for an actual implementation. Great! After this, let's fix properties. ;) [...] What I'd like to know, is how all of these proposals address the fundamental differences between symbol tuples (compile-time construct) and std.range.Tuple (runtime construct). As far as I can tell, people are still confusing the two, and it's really not helping. Before we solve this, any syntax suggestion seems more like a mortician's work than a real solution. T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Re: Language and library reference pages very slow to load
On Mon, Aug 19, 2013 at 09:21:58AM -0700, Andrei Alexandrescu wrote: On 8/18/13 10:28 PM, H. S. Teoh wrote: On Mon, Aug 19, 2013 at 06:42:04AM +0200, finalpatch wrote: Apparently the javascript that's responsible for creating hyperlinks runs very slowly, usually several seconds or longer. eg. http://dlang.org/phobos/core_memory.html is so slow it causes Mozilla Firefox to pop up the page not responding box. I have also tried Internet Explorer 10 on Windows 7 and Safari on Mac OS X 10.8.4 and got similar results. I wonder if it's possible to move this to the server side given the documents are mostly static contents. My guess is that this is caused either by hyphenate.js or hyphenate-selectively.js, both of which, thankfully, will be going away once dlang.org is updated (their removal has already been merged into git HEAD). Wasn't JS hyphenation only removed for browsers that support hyphenation at CSS level? [...] If that's the case, then it should be completely removed. Let CSS hyphenation take care of the case where browsers actually support it. Please, *please* let's not go back to JS hyphenation. We've gotten nothing but an endless stream of complaints about it over the last couple o' months (or more). People are having trouble browsing dlang.org because it's either too slow, or their browsers pop up warnings about long-running scripts, and all for what? Some textual cosmetics? What a perfect way to turn people off D. T -- If it breaks, you get to keep both pieces. -- Software disclaimer notice
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 16:53:06 UTC, Wyatt wrote:
Note: I'm leading off with a reply to bearophile transplanted
here to stop making OT noise in John's thread about TypeTuple.
On Friday, 16 August 2013 at 23:23:59 UTC, bearophile wrote:
It's short, clear, has a precedent with q{}.
Wait, what is q{}? That's something in D? What does that even
do? I can infer that q{} is probably some manner of scoping or
grouping _something_ somehow, but I have to dig into lexical
and manually search for q{ to find out it's [neither of the
things I expected]. In my view, this right here is really just
a fundamental problem with single-character prefixes and I feel
that's something we should endeavour to avoid, if possible.
I don't like it a lot, but it's way better than not having
language support for tuples.
On this, I think we all agree.
I'd prefer just using parentheses, but I think there were
readability problems that caused the DIP to end up with:
More than just readability problems. They were discussed when
Kenji presented the DIP 32 in this forum. Timon found a
significant problem with the {} syntax.
To be clear, I'm not talking about braces, {}; I'm talking
about parentheses, (). I read over that whole DIP32 thread a
couple times, and didn't see any rationale offered for why the
likely cleanest version can't be used. It wasn't even
brought up (unless I've missed something subtle). In the
second thread, linked in the OP here, they were glossed over
again. Now, I fully believe there's a very good reason that's
been written somewhere, but I _would_ like to know what that
is, preferably documented somewhere less ephemeral and
difficult to search than the newsgroup (such as in DIP32). The
closest I've seen so far is the pull request where Walter and
Andrei expressed that it should be considered further.
On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
- #(a, b) is unambiguous and would probably be the easiest
option. I don't think it looks too bad, but some people might
find it ugly and noisy
The octothorpe _is_ much better than the t simply in terms of
readability, though, even more than q{} or t{}, I have concerns
about its ability to be found with an ordinary search engine by
an ordinary user. Have you tried looking for documentation on
weird operators with a search engine lately? They don't
exactly take to it well. :/ (cf. Perl's =)
All we have left from the standard keyboard layout as far as
single keys go is # and ¬
I don't think the mathematics crowd would be too happy with ¬ not
meaning not.
The only op() options I can think of that aren't ambiguous:
$(a, b)
%(a, b)
^(a, b)
(a, b) //I like this one
:(a, b)
#(a, b)
'(a, b) //I think
/(a, b)
\(a, b)
(a, b)
(a, b)
|(a, b)
¬(a, b) //not in std ascii
?(a, b)
however, most of those are binary operators too, so it could be
quite accident prone and confusing to look at
Some of this could be helped by enforcing at least 1 ','.
e.g.
(3) //illegal
(3,) //legal
There is precedent for this in python.
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote: What I'd like to know, is how all of these proposals address the fundamental differences between symbol tuples (compile-time construct) Those are not symbol tuples. For example, `int` is not a symbol. http://dlang.org/template.html#Symbol - only things that have identifiers and template instances are symbols. As far as I can tell, people are still confusing the two, and it's really not helping. Completely removing TypeTuple from library (which native syntax will enable) will help to remove large part of confusion.
Re: trusted purity?
On Monday, 19 August 2013 at 12:55:54 UTC, bearophile wrote: For the function array() this is not enough, because instead of = void you have a function that returns some void-initialized data. To help the D type system a bit perhaps an annotations like @void_init is useful, to be attached to functions like uninitializedArray and minimallyInitializedArray. Bye, bearophile After re-reading pure documentation, I think I can solve the problem by marking uninitialized/minimallyInitialized as weakly pure. From there using it in a pure context is trivial. This is in line with what GC.malloc does.
Re: Language and library reference pages very slow to load
On Mon, 19 Aug 2013 09:21:58 -0700 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 8/18/13 10:28 PM, H. S. Teoh wrote: My guess is that this is caused either by hyphenate.js or hyphenate-selectively.js, both of which, thankfully, will be going away once dlang.org is updated (their removal has already been merged into git HEAD). Wasn't JS hyphenation only removed for browsers that support hyphenation at CSS level? I hope not. We really don't need the hyphenation. I know you like it, but I have yet to see one other person who cares about it. Plus, loading speed is far more important anyway.
Re: Any cryptographically secure pseudo-random number generator (CSPRNG) for D?
On 8/19/2013 8:56 AM, ilya-stromberg wrote: On Sunday, 18 August 2013 at 19:32:50 UTC, QAston wrote: You may be interested in https://github.com/D-Programming-Deimos/openssl - D bindings for openssl. How can I get access to the /dev/random or /dev/urandom (Linux only)? Like a file via std.file, or D have spesial function? Access using the usual file I/O functions.
Re: When compiling multiple source files
On Monday, 19 August 2013 at 17:15:35 UTC, ProgrammingGhost wrote: On Monday, 19 August 2013 at 11:01:54 UTC, Jacob Carlborg wrote: The compiler will start compiling the files passed on the command line. It will read the files asynchronously and then lex, parse build an AST and do semantic analyze. When the semantic analyze is done it will have access to all import declarations. It basically starts the same processes for all these imports, recursively. The reason for waiting until semantic analyze is done because you can have code looking like this: mixin(import foo;); The expansion of the mixin and other similar features are done in the semantic analyze phase. So everything is parsed once and kept in memory until the compiler finish every source file? Is there any ram problems when compiling large codebases? Unfortunately, yes, if you give dmd a very large number of files all at once, it will chew through all your free RAM. But dmd does support separate compilation: $dmd file1.d -c $dmd file2.d -c $dmd file1.o file2.o which alleviates the problem. My experience with D is limited. Are libraries the same as C libraries? From my understanding the linker figures that part out and the compiler needs a separate file for the definition. If I build a library in D is it the same as a C library or different which includes function definitions? Sorry if I'm confused I know almost nothing about D. I stick to .NET, java and C++ Libraries in D use the same formats as C/C++ libraries.
Re: Static unittests?
On Sunday, 18 August 2013 at 20:35:06 UTC, Walter Bright wrote:
On 8/5/2013 11:27 AM, monarch_dodra wrote:
What about, for example:
assertCTFEable!({
int i = 5;
string s;
while (i--)
s ~= 'a';
assert(s == a);
});
I don't believe that is a valid use case because the code being
tested is not accessible from anything other than the test.
I'm not sure what that means. Isn't that the case of all unittest?
In any case, I was just saying the above template was enough for
our needs, and that I don't think a language solution is in
order. Also, I think the:
//
unittest
{
void dg()
{
BODY OF UNITTEST
}
dg(); //test runtime
assertCTFEable!dg; //test compiletime
}
//
usecase makes it useful. Although arguably, you could just:
//
unittest
{
bool dg()
{
BODY OF UNITTEST
return true;
}
dg(); //test runtime
enum a = dg();
or
static assert(dg);
}
//
But really, I'm just saying why type that when the template does
it pretty well for us, while being self-docuenting?
Re: A Discussion of Tuple Syntax
On Mon, Aug 19, 2013 at 07:34:38PM +0200, Dicebot wrote: On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote: What I'd like to know, is how all of these proposals address the fundamental differences between symbol tuples (compile-time construct) Those are not symbol tuples. For example, `int` is not a symbol. http://dlang.org/template.html#Symbol - only things that have identifiers and template instances are symbols. Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. See, part of the problem is that they just don't have any good name that correctly conveys what they are. Calling them tuple only adds to the confusion because of the conflation with std.range.Tuple. As far as I can tell, people are still confusing the two, and it's really not helping. Completely removing TypeTuple from library (which native syntax will enable) will help to remove large part of confusion. That's only part of the problem. It doesn't solve the problem of conflation between these tuples and std.range.Tuple, and from what I can tell in these threads, people are still confusing the two. Both of them being named some kind of tuple doesn't help the problem. This is one of the things about D that's seriously WAT-worthy. T -- If it breaks, you get to keep both pieces. -- Software disclaimer notice
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 17:45:44 UTC, H. S. Teoh wrote: On Mon, Aug 19, 2013 at 07:34:38PM +0200, Dicebot wrote: On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote: What I'd like to know, is how all of these proposals address the fundamental differences between symbol tuples (compile-time construct) Those are not symbol tuples. For example, `int` is not a symbol. http://dlang.org/template.html#Symbol - only things that have identifiers and template instances are symbols. Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. Well, technically they are compile-time tuples of stuff. Yep, that bad :) They don't have a good name because they don't have a good meaning, only behavior. See, part of the problem is that they just don't have any good name that correctly conveys what they are. Calling them tuple only adds to the confusion because of the conflation with std.range.Tuple. std.typecons.Tuple ;) I have noticed it is not the first time you want to move it to std.range ;) Well, you see, they are really both tuples. That is also the problem - call them whatever you want but they still both will be tuples. Compile-time tuple and run-time tuple, that is it (and I was recently surprised to learn that even their implementations are deeply tied). I don't think simply changing a name to something irrelevant will magically solve confusion, it is feature in general that need clear re-definition in all relevant documentation. Tuple entry on dlang.org does not mention even half of the truth about it...
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote: What I'd like to know, is how all of these proposals address the fundamental differences between symbol tuples (compile-time construct) and std.range.Tuple (runtime construct). As far as I can tell, people are still confusing the two, and it's really not helping. Before we solve this, any syntax suggestion seems more like a mortician's work than a real solution. As far as I can tell, when everyone talks about tuple syntax, they are talking about run-time tuples. That's definitely what I'm talking about whenever I mention tuple syntax, as I don't think it would be a good thing to use it for both run-time and compile-time tuples (and I don't really consider the latter tuples). Bearophile has mentioned a couple times that we could use the tuple syntax for both, and bring about a unification of these two tuple types. I don't like this, as they're both very different entities, and don't really have any relation to each-other whatsoever. I think the best course of action is to keep TypeTuples as is (and possibly provide a new name for them, underdocumenting or outright deprecating the old name), and introduce the new syntax for run-time tuples. Speaking of new names for TypeTuple, I don't know if this was mentioned already, but what about Variadic Lists?
Re: Language and library reference pages very slow to load
On 8/19/13 10:32 AM, H. S. Teoh wrote: On Mon, Aug 19, 2013 at 09:21:58AM -0700, Andrei Alexandrescu wrote: On 8/18/13 10:28 PM, H. S. Teoh wrote: On Mon, Aug 19, 2013 at 06:42:04AM +0200, finalpatch wrote: Apparently the javascript that's responsible for creating hyperlinks runs very slowly, usually several seconds or longer. eg. http://dlang.org/phobos/core_memory.html is so slow it causes Mozilla Firefox to pop up the page not responding box. I have also tried Internet Explorer 10 on Windows 7 and Safari on Mac OS X 10.8.4 and got similar results. I wonder if it's possible to move this to the server side given the documents are mostly static contents. My guess is that this is caused either by hyphenate.js or hyphenate-selectively.js, both of which, thankfully, will be going away once dlang.org is updated (their removal has already been merged into git HEAD). Wasn't JS hyphenation only removed for browsers that support hyphenation at CSS level? [...] If that's the case, then it should be completely removed. Well, looks like I missed https://github.com/D-Programming-Language/dlang.org/pull/367. Andrei
Unable to build deimos/libX11 with ldc2
I got ldc2 from github and built it following this tutorial: http://wiki.dlang.org/Building_LDC_from_source . The ldc build and install went fine but when I try to build libX11 with it, I get the following errors: $make -j2 sh: arch: command not found Makefile:159: warning: overriding recipe for target `install' Makefile:156: warning: ignoring old recipe for target `install' ldc2 -O -d -m64 -L-ldl -m64 -c deimos/X11/Xlibint.d -ofbuild/deimos/X11/Xlibint.o sh: arch: command not found ldc2 -O -d -m64 -L-ldl -m64 -c deimos/X11/keysym.d -ofbuild/deimos/X11/keysym.o sh: arch: command not found ldc2 -O -d -m64 -L-ldl -m64 -c deimos/X11/Xproto.d -ofbuild/deimos/X11/Xproto.o sh: arch: command not found deimos/X11/Xlibint.d(895): Error: Function type does not match previously declared function with the same mangled name: Data make: *** [build/deimos/X11/Xlibint.o] Error 1 make: *** Waiting for unfinished jobs Any clues ?
Re: std.serialization: pre-voting review / discussion
Am Mon, 19 Aug 2013 16:21:44 +0200
schrieb Tyler Jameson Little beatgam...@gmail.com:
On Monday, 19 August 2013 at 13:31:27 UTC, Jacob Carlborg wrote:
On 2013-08-19 15:03, Dicebot wrote:
Great! Are there any difficulties with the input?
It just that I don't clearly know how the code will need to
look like, and I'm not particular familiar with implementing
range based code.
Maybe we need some kind of doc explaining the idiomatic usage of
ranges?
Personally, I'd like to do something like this:
auto archive = new XmlArchive!(char); // create an XML archive
auto serializer = new Serializer(archive); // create the
serializer
serializer.serialize(foo);
pipe(archive.out, someFile);
Your pipe function is the same as std.algorithm.copy(InputRange,
OutputRange) or std.range.put(OutputRange, InputRange);
An important question regarding ranges for std.serialization is whether
we want it to work as an InputRange or if it should _take_ an
OutputRange. So the question is
-
auto archive = new Archive();
Serializer(archive).serialize(object);
//Archive takes OutputRange, writes to it
archive.writeTo(OutputRange);
vs
auto archive = new Archive()
Serializer(archive).serialize(object);
//Archive implements InputRange for ubyte[]
foreach(ubyte[] data; archive) {}
-
I'd use the first approach as it should be simpler to implement. The
second approach would be useful if the ubyte[] elements were processed
via other ranges (map, take, ...). But as binary data is usually
not processed in this way but just stored to disk or sent over network
(basically streaming operations) the first approach should be fine.
The first approach has the additional benefit that we can easily do
streaming like this:
auto archive = new Archive(OutputRange);
//Immediately write the data to the output range
Serializer(archive).serialize([1,2,3]);
This is difficult to implement with the second approach as you somehow
have to interleave calls to serialize and reads to the InputRange
interface:
Serializer(archive).serialize(1);
foreach(data; archive) {stdout.write(data);}
Serializer(archive).serialize(2);
foreach(data; archive) {stdout.write(data);}
And it's still less efficient than approach 1 as it has to keep an
internal buffer.
Another point is that serialize in the above example could be
renamed to put. This way Serializer would itself be an OutputRange
which allows stuff like [1,2,3,4,5].stride(2).take(2).copy(archive);
Then serialize could also accept InputRanges to allow this:
archive.serialize([1,2,3,4,5].stride(2).take(2));
However, this use case is already covered by using copy so it would just
be for convenience.
Re: A Discussion of Tuple Syntax
On 8/19/13 10:54 AM, Dicebot wrote: On Monday, 19 August 2013 at 17:45:44 UTC, H. S. Teoh wrote: On Mon, Aug 19, 2013 at 07:34:38PM +0200, Dicebot wrote: On Monday, 19 August 2013 at 17:22:26 UTC, H. S. Teoh wrote: What I'd like to know, is how all of these proposals address the fundamental differences between symbol tuples (compile-time construct) Those are not symbol tuples. For example, `int` is not a symbol. http://dlang.org/template.html#Symbol - only things that have identifiers and template instances are symbols. Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. Well, technically they are compile-time tuples of stuff. I'd call them alias tuples. Andrei
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 17:57:45 UTC, Meta wrote: As far as I can tell, when everyone talks about tuple syntax, they are talking about run-time tuples. That's definitely what I'm talking about whenever I mention tuple syntax, as I don't think it would be a good thing to use it for both run-time and compile-time tuples (and I don't really consider the latter tuples). No. I speak exclusively about native syntax for compile-time tuples and stand by the point that run-time tuples are mostly fine as-is and should not be touched at all.
Re: Ideas for a brand new widget toolkit
On Friday, 16 August 2013 at 12:36:39 UTC, Wyatt wrote: On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote: I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases. As Andrei and I have pointed out, NX does a much better job of things. If nothing else, read the explanation of how it works-- there are perceptual subtleties to this that aren't apparent at first glance: http://www.nomachine.com/documents/NX-XProtocolCompression.php I don't much care if X11 can be made faster. Unless you plan on bundling an X server with your Windows app, it's not an option for a cross-platform GUI. In any case, if X11 is in fact similar to the approach I laid out, I obviously think that approach can be done speedily, though X11 probably bites off too much whereas I carefully constrained the problem for my Crack client.
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:11:34 UTC, Andrei Alexandrescu wrote: I'd call them alias tuples. Because we don't have strict definition of alias too? :) Actually, I have forgot again that built-in tuples are not always compile-time. They can be used to declare run-time entities with tuple syntax too, that was exactly what was abused in std.typecons.Tuple implementation. As I have already said, it is hard to name something that does not have clear semantics and is essentially just random collection of behavior.
Re: A Discussion of Tuple Syntax
Wyatt:
The octothorpe _is_ much better than the t simply in terms of
readability, though, even more than q{} or t{}, I have concerns
about its ability to be found with an ordinary search engine by
an ordinary user. Have you tried looking for documentation on
weird operators with a search engine lately? They don't
exactly take to it well. :/ (cf. Perl's =)
I think none of the suggested tuple syntaxes are well searchable
on Google, but the tuple() syntax.
But in the Haskell world the Hoogle directreverse search engine
supports symbols too (but it's mostly used to search for
functions given their signature, I think so far this is something
not present in the D world):
http://www.haskell.org/hoogle/?hoogle=%3D%3E
I even don't like how the unicode version of that one looks;
It was just an idea, to show what I meant by representing the
bananas with Unicode glyphs. The actual choice of glyphs is not
an urgent choice :-) The idea comes from the now dead Fortress
language.
I feel weird admitting this, but if we can't use some manner of
bare brace, I think I'd rather have tup(), tup[], tup{} (or
even tuple() et al) as a prefix over any single character.
At the moment I prefer #() syntax, with ? for single wildcards.
It's better than tup{} or t{} because the # symbol pops out more
visually. tuple() syntax is long, but it's readable, and perhaps
partially backwards compatible.
Can't make it a single underscore? Question mark works best
then, IMO. It isn't as burdened with meanings elsewhere (sure
there's ternary and possibly-match in regex, but...have I
forgotten something?)
The ? of regexes is inside strings, so I think it causes no
problems. And I think it doesn't clash with the ternary operator
because before the ? wildcard you put a comma, a semicolon or a
#(.
Assuming the ... syntax for unpacking, it would be useful to
name the captured tail. For example, you could unpack #(1, 3,
#(4, 6)) into #(a, b, x...), where a = 1, b = 3, x = #(4, 6).
Similarly, #(head, rest...) results in head = 1, rest = #(2,
#(4, 6)). I think this would be very useful.
In Haskell there is also a way to give a name to the whole tuple
and names to its parts:
Prelude let t1 = (10, 20)
Prelude let a@(b, c) = t1
Prelude a
(10,20)
Prelude b
10
Prelude c
20
-
Meta:
Bearophile has mentioned a couple times that we could use the
tuple syntax for both, and bring about a unification of these
two tuple types. I don't like this, as they're both very
different entities, and don't really have any relation to
each-other whatsoever.
Mine was an idea, but if it turns out to be a bad idea, then
let's ignore it.
Bye,
bearophile
Re: Unable to build deimos/libX11 with ldc2
On Monday, 19 August 2013 at 18:05:41 UTC, Paul Z. Barsan wrote: deimos/X11/Xlibint.d(895): Error: Function type does not match previously declared function with the same mangled name: Data Without having looked at the libX11 sources at all, the error message implies that there are multiple extern(C) function declarations named Data that have different types. This is likely an issue with the libX11 bindings and should be fixed there. DMD doesn't care about that, but in LDC we would have to specifically work around a related LLVM restriction to be able to accept that code. Oh, and in the future, you might want to post similar questions to digitalmars.D.learn. David
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:19:11 UTC, bearophile wrote:
Mine was an idea, but if it turns out to be a bad idea, then
let's ignore it.
I was initially completely opposed against it but now that I have
realized built-in ones do some run-time magic too, it does not
sound _that_ crazy anymore.
Seriously, if current std.typecons.Tuple is implemented in terms
if built-in tuple, than it sounds like only think built-in ones
are lacking is ABI. Define it and using one single tuple syntax /
implementation for everything becomes real.
I mean:
import std.typecons;
import std.typetuple;
void main()
{
alias TT = TypeTuple!(int, string);
// moar confusion for gods of confusion!
// what is the difference between twoVars1 and twoVars2
other than latter is wrapped into struct and has ABI?
TT twoVars1;
Tuple!(int, string) twoVars2;
}
Experience report: teaching D at a summer course at University of Minnesota
http://www.reddit.com/r/programming/comments/1ko94o/experience_report_teaching_d_at_a_summer_course/
Re: A Discussion of Tuple Syntax
On Mon, Aug 19, 2013 at 08:10:38PM +0200, Dicebot wrote: On Monday, 19 August 2013 at 17:57:45 UTC, Meta wrote: As far as I can tell, when everyone talks about tuple syntax, they are talking about run-time tuples. That's definitely what I'm talking about whenever I mention tuple syntax, as I don't think it would be a good thing to use it for both run-time and compile-time tuples (and I don't really consider the latter tuples). No. I speak exclusively about native syntax for compile-time tuples and stand by the point that run-time tuples are mostly fine as-is and should not be touched at all. Case in point. :) So we're actually talking at cross purposes here. Bearophile Meta et al want native syntax for *runtime* tuples (i.e. std.typecons.Tuple -- sorry for the mixup with std.range in my earlier posts), but you're talking about native syntax for alias tuples (aka TypeTuples). Two completely different things. I agree that we shouldn't be making built-in syntax for a library type. If anything, any dedicated syntax should be reserved for alias tuples (aka std.typetuple.Typetuple). Or, at the very least, rename TypeTuple to AliasTuple. Conflating these two concepts has led to endless confusion, which is why I insisted on addressing this issue before we even begin to talk about syntax. Otherwise we're going nowhere. T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 16:53:06 UTC, Wyatt wrote:
To be clear, I'm not talking about braces, {}; I'm talking
about parentheses, (). I read over that whole DIP32 thread a
couple times, and didn't see any rationale offered for why the
likely cleanest version can't be used. It wasn't even
brought up (unless I've missed something subtle). In the
second thread, linked in the OP here, they were glossed over
again. Now, I fully believe there's a very good reason that's
been written somewhere, but I _would_ like to know what that
is, preferably documented somewhere less ephemeral and
difficult to search than the newsgroup (such as in DIP32). The
closest I've seen so far is the pull request where Walter and
Andrei expressed that it should be considered further.
I could very well be wrong, but I would bet that one of the
reasons is that (a, b, c) expressions already have well-defined
semantics in D (as well as (2, a, func()). Example:
void main()
{
import std.stdio;
//Prints a
writeln((true, false, a));
}
Making this a tuple literal would be a change in semantics, which
I don't think would go over well and would break code. Another
example:
void main()
{
int a, b;
(a, b) = (3, 4);
assert(a == 0 b == 4);
}
Of course, for the second case, Kenji's proposed syntax used
auto (a, b) = ..., which would disambiguate it, but it could
confuse people as to whether the first syntax is somehow related
to the second.
The octothorpe _is_ much better than the t simply in terms of
readability, though, even more than q{} or t{}, I have concerns
about its ability to be found with an ordinary search engine by
an ordinary user. Have you tried looking for documentation on
weird operators with a search engine lately? They don't
exactly take to it well. :/ (cf. Perl's =)
I'm not sure how much of a problem that would be. There's only
one other syntactic form that uses # in D, but you're right, it
may cause some difficulty trying to search d programming #.
Addressing the other suggestion I saw that cropped up, I
personally find the two-character bananas to be impressively
ugly. I considered suggesting some permutation on that same
idea, but after toying with a few examples I find it ends up
looking awful and I think it's honestly annoying to type them
in any form. I even don't like how the unicode version of that
one looks; for doubling up, I think ⟦ ⟧ or ⟪ ⟫ or are easier on
the eyes.
My browser can't even display the second set of characters. D
seems to have generally shied away from using any unicode
operators (for a good reason. Who the hell has Σ on their
keyboard?)
I feel weird admitting this, but if we can't use some manner of
bare brace, I think I'd rather have tup(), tup[], tup{} (or
even tuple() et al) as a prefix over any single character.
It's not terrible, but it's rather wordy, especially if tuples
begin to be used a lot in code.
Can't make it a single underscore? Question mark works best
then, IMO. It isn't as burdened with meanings elsewhere (sure
there's ternary and possibly-match in regex, but...have I
forgotten something?)
It *could* be an underscore; the only thing is that the
underscore is a valid variable name, so the above expression
would actually be binding two variables, which might surprise
someone who was expecting otherwise. I don't really care all that
much, but it's something to think about.
#(a, ...) looks like to me like it would make a 2-tuple
containing a and a tuple of everything else, because of the
ellipsis' use in templated code. I think this is a little
unclear, so instead I'd prefer #(a, ? ...) (or whatever ends up
used for the discard character) to make it explicit.
To be clear, what I have in mind is that this would be a, plus
(none/one?) or more things that can either be elements or nested
tuples. Then, in a construction such as #(head, rest...), rest
would be exactly as you describe: a tuple consisting of
everything after head. The semantics could get tricky, maybe this
needs more thought.
As a bonus, explicit discard means a simple comma omission is
less likely to completely change the meaning of the statement.
Compare:
#(a, b, ...) //bind the first two elements, discard the rest.
#(a, b ...)//bind the first element to a and everything
else to b
#(a, b, ? ...) //same as the first
#(a, b ? ...) //syntax error
Granted, there's this case:
#(a, ?, ...)
...but that seems like it would be less common just based on
how people conventionally order their data structures.
That's true. Something to think about. Maybe combine the question
mark and ellipsis like so:
#(a, b, ?..)
Thought: Is there sufficient worth in having different tokens
for discarding a single element vs. a range? e.g.
#(a, ?, c, * ...) //bind first and third elements; discard the
rest
// I'm not attached to the asterisk there.
// +, #, or @ would also make
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:19:11 UTC, bearophile wrote: The ? of regexes is inside strings, so I think it causes no problems. And I think it doesn't clash with the ternary operator because before the ? wildcard you put a comma, a semicolon or a #(. I was primarily addressing the fact that there aren't many _meanings_ attached to the same character. This was brought up before when someone talked about using an asterisk, but it was pointed out that it would be a bad choice because it's already commonly seen in multiplication, pointers, and exponentiation (**). If anything, I'm inclined to think the regex heritage of the question mark improves its case. -Wyatt
Re: A Discussion of Tuple Syntax
Realistically, Andrei, how amenable are you and Walter to adding tuple literal/packingunpacking/pattern matching syntax to D, be it Tuple, TypeTuple, whatever? I don't recall either of you commenting much in the two other discussion threads linked. We can discuss this all day, but it what are the actual chances of you agreeing to such a large change in the language?
Re: std.serialization: pre-voting review / discussion
19-Aug-2013 22:05, Johannes Pfau пишет: Am Mon, 19 Aug 2013 16:21:44 +0200 schrieb Tyler Jameson Little beatgam...@gmail.com: Another point is that serialize in the above example could be renamed to put. This way Serializer would itself be an OutputRange which allows stuff like [1,2,3,4,5].stride(2).take(2).copy(archive); +1 I totally expect serializer to be a sink. Then serialize could also accept InputRanges to allow this: archive.serialize([1,2,3,4,5].stride(2).take(2)); However, this use case is already covered by using copy so it would just be for convenience. -- Dmitry Olshansky
Re: Unable to build deimos/libX11 with ldc2
Oh, sorry for using the wrong forum section. I used the dmd compiler and the build went fine. Is pretty weird though because ldc2 is the default compiler used to build libX11. I filed an issue report for deimos/libX11 on their project page.
Re: A Discussion of Tuple Syntax
On 08/19/2013 07:44 PM, H. S. Teoh wrote: Well, OK, whatever they're supposed to be called. Compiler-tuples, or expression tuples, or whatever. See, part of the problem is that they just don't have any good name that correctly conveys what they are. They are simply template argument lists. (http://wiki.dlang.org/The_D_Programming_Language/Seq)
Re: Unable to build deimos/libX11 with ldc2
BTW what do you plan to do with the libx11? You might find my simpledisplay.d (also depends on color.d) interesting from my miscellaneous github: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff It provides a class called SimpleWindow that supports basic drawing and some input stuff (input is in the middle of an overhaul right now, I'm fixing a lot of bugs and will be posting that new code online in a few days, but even right now it still works for checking ascii keys at least), on top of Xlib, with equivalent code for Windows in there too so your same program can compile cross platform. Though I've never tried to compile it on ldc either, I did my own xlib bindings (included in the same simpledisplay.d file) so it might work; surely won't have the *same* bugs at least.
Re: std.serialization: pre-voting review / discussion
On Monday, 19 August 2013 at 14:47:15 UTC, bsd wrote: I think this versioning idea is more important for protocol buffers, msgpck, thrift like libraries that use a separate IDL schema and IDL-compiled code. std.serialization uses the D code itself to serialize so the version is practically dictated by the user. It may as well be manually handledas long as it throws/returns error and doesn't crash if one tries to deserialize an archive type into a different/modified D type. From memory the Protocol Buffers versioning is to ensure schema generated code and library are compatible. You get compile errors if you try to compile IDL generated code with a newer version of the library. Similarly you get runtime errors if you deserialize data that was serialized with an older version of the library. This is all from memory so I could be wrong... Seems like your memory has indeed faded a bit. ;) Versioning is an integral idea of formats like Protobuf and Thrift. For example, see the A bit of history section right on the doc overview page. [1] You might also want to read through the (rather dated) Thrift whitepaper to get an idea about what the design constraints for it were. [2] The main point is that when you have deployed services at the scale Google or Facebook work with, you can't just upgrade all involved parties simultaneously on a schema change. So, having to support multiple versions running along each other is pretty much a given, and the best way to deal with that is to build it right into your protocols. David [1] https://developers.google.com/protocol-buffers/docs/overview [2] http://thrift.apache.org/static/files/thrift-20070401.pdf
Re: Unable to build deimos/libX11 with ldc2
On Monday, 19 August 2013 at 19:25:03 UTC, Adam D. Ruppe wrote: BTW what do you plan to do with the libx11? It's a dependency for Cairo. I want to use Cairo for drawing stuff on the screen. This library is also used by GTK 3 to render all their widgets.Besides that, it supports multiple platforms :). I started my widget toolkit project on github: https://github.com/tyrolite/wkd and I'll make an anouncement on the other thread once I have the code to draw a button. I'll probably get faster there using parts of your code. Thanks !
Re: A Discussion of Tuple Syntax
Meta:
It *could* be an underscore; the only thing is that the
underscore is a valid variable name, so the above expression
would actually be binding two variables, which might surprise
someone who was expecting otherwise. I don't really care all
that much, but it's something to think about.
You can't define a variable more than once in a scope, so this
can't be valid:
void main() {
auto t1 = #(5, hello, 1.5);
auto (_, _, x) = t1;
auto (_, gr, _) = t1;
}
While ? defines nothing, so this is OK:
void main() {
auto t1 = #(5, hello, 1.5);
auto (?, ?, x) = t1;
auto (?, gr, ?) = t1;
}
Bye,
bearophile
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 19:54:43 UTC, bearophile wrote: ... That too.
Re: A Discussion of Tuple Syntax
void main() {
auto t1 = #(5, hello, 1.5);
auto (_, _, x) = t1;
auto (_, gr, _) = t1;
}
I need to get used to the proposed syntax, sorry:
void main() {
auto t1 = #(5, hello, 1.5);
auto #(_, _, x) = t1;
auto #(_, gr, _) = t1;
}
Bye,
bearophile
