Re: Low feature GNUPlot controller for D2
On Sunday, 11 March 2012 at 21:45:02 UTC, SiegeLord wrote: Anyway, the repository for it is here: https://github.com/SiegeLord/DGnuplot It requires TangoD2 to build and gnuplot 4.4.3 to run (unless you're saving commands to a file as described above). It works on Linux, and maybe on Windows (untested). -SiegeLord I just tried this on Win7 64 bit using the latest TangoD2 and the gnuplot from this link http://sourceforge.net/projects/gnuplot/files/ I had to substitute pgnuplot.exe, which is one of the windows gnuplot exe versions that accepts the piped input GNUPlot = new Process(true, pgnuplot.exe -persist); With that change one of the graphs displayed, the one with title Raw gnuplot commands. The rest all failed, maybe due to the binary record input, which they try to echo to their text command shell. Maybe if there were an option to use text format input, or maybe there is some terminator expected. Their command shell fails to return to the prompt after echoing the binary data, and doesn't create the graph shell on these others that use the binary record input.
Re: Low feature GNUPlot controller for D2
On Wednesday, 14 March 2012 at 07:16:39 UTC, Jay Norwood wrote: I just tried this on Win7 64 bit using the latest TangoD2 and the gnuplot from this link http://sourceforge.net/projects/gnuplot/files/ I had to substitute pgnuplot.exe, which is one of the windows gnuplot exe versions that accepts the piped input GNUPlot = new Process(true, pgnuplot.exe -persist); With that change one of the graphs displayed, the one with title Raw gnuplot commands. The rest all failed, maybe due to the binary record input, which they try to echo to their text command shell. Maybe if there were an option to use text format input, or maybe there is some terminator expected. Their command shell fails to return to the prompt after echoing the binary data, and doesn't create the graph shell on these others that use the binary record input. There was discussion of windows problems with the binary data input elsewhere, including some discussion of the input being opened in text mode. Looks like the cygwin version might be a solution. http://octave.1599824.n4.nabble.com/Gnuplot-scripts-as-output-td1680624.html http://sourceforge.net/tracker/?func=detailatid=102055aid=2981027group_id=2055
Visual D 0.3.31 features GDC support
Hi, the new version of Visual D includes support for building and debugging D projects with GDC, both Win32 and x64. Here is a list of major changes: 2012-03-14 Version 0.3.31 * added support for building with GDC * added platform support for x64 (use with GDC only) * includes new version 0.23 of cv2pdb that now also converts DWARF to pdb * added option to Intellisense page to configure trigger of code completion * new version of mago with bug fixes and support for associative arrays in expressions with basic key types * property: fixed editing multiple configurations at once * added Compile command to syntax check the current source file * parser now supports new lambda syntax (x) = x * fix resource include with spaces Very short instructions on how to get started with GDC can be found here: http://www.dsource.org/projects/visuald/wiki/Installation#UsingGDC Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005-11 as well as the free Visual Studio Shells. The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald Rainer
Re: Visual D 0.3.31 features GDC support
On 14.03.2012 11:46, Rainer Schuetze wrote: Hi, the new version of Visual D includes support for building and debugging D projects with GDC, both Win32 and x64. Wow! Now that's a killer feature! Here is a list of major changes: 2012-03-14 Version 0.3.31 * added support for building with GDC * added platform support for x64 (use with GDC only) * includes new version 0.23 of cv2pdb that now also converts DWARF to pdb * added option to Intellisense page to configure trigger of code completion * new version of mago with bug fixes and support for associative arrays in expressions with basic key types * property: fixed editing multiple configurations at once * added Compile command to syntax check the current source file * parser now supports new lambda syntax (x) = x * fix resource include with spaces Very short instructions on how to get started with GDC can be found here: http://www.dsource.org/projects/visuald/wiki/Installation#UsingGDC Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005-11 as well as the free Visual Studio Shells. The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald Rainer -- Dmitry Olshansky
Re: Pegged, From EBNF to PEG
On 14.03.2012 2:49, Philippe Sigaud wrote:
On Tue, Mar 13, 2012 at 17:17, Dmitry Olshanskydmitry.o...@gmail.com wrote:
PEG defines order of alternatives, that is pretty much like a top-down
recursive descent parser would parse it. Alternatives are tried from left to
right, if first one fails, it tries next and so on.
Yes.
In an example I give B is always picked first and so C is never ever looked
at.
That's one of the caveats on PEG. That and greedy operators.
'a*a' never succeeds because 'a*' consumes all the available a's.
Hey, wait, I thought there has to be backtrack here, i.e. when second
'a' finally fails?
Literal- (' .+ ') / ('' .+ '')
This needs escaping. Plain '.+' in pattern asks for trouble 99% of time.
This is an example were PEG would munch anything till the end, and
fail (since is not found in an empty string).
The standard PEG way to do that is
(!EndMarker .)+ EndMarker
It's a common enough pattern I tend to define a parameterized rule for that:
Until(Expr)- (!Expr .)* Expr
Gotta love parametrized rules! 15' to code, a neverending stream of joy.
Nice!
In fact grammars are usually devised the other way around, e.g.
Start:
Program - ...
Ehm... what the whole program is exactly ? Ok, let it be Declaration* for
now. What kind of declarations do we have? ... and so on. Latter grammars
get tweaked and extended numerous times.
At any rate production order has no effect on the grammar, it's still the
same. The only thing of importance is what non-terminal considered final (or
start if you are LL-centric).
Yes. The PEG standard seem to be that the first rule is the start
(root) rule. Pegged let you decide which rule you use for a start. The
rest is automatic.
I might change that.
--
Dmitry Olshansky
Re: Visual D 0.3.31 features GDC support
On Wednesday, 14 March 2012 at 07:46:35 UTC, Rainer Schuetze wrote: * property: fixed editing multiple configurations at once Very happy to finally see this get fixed. In actual VisualD use, these issues are the most urgent. Thanks, and keep the project management improvements coming - I can't think of anything more important than getting the basics down!
Re: Visual D 0.3.31 features GDC support
Rainer Schuetze wrote: Hi, the new version of Visual D includes support for building and debugging D projects with GDC, both Win32 and x64. Cool! Keep up the good work! I can't wait to test my projects with GDC-win...
Re: std.log review suspended
Am Tue, 13 Mar 2012 19:18:31 +0100 schrieb Johannes Pfau nos...@example.com: Am Tue, 13 Mar 2012 00:07:01 +0100 schrieb David Nadlinger s...@klickverbot.at: The extended review period for std.log has ended [1], and Jose, the author of the proposed module, has requested some extra time to incorporate the suggestions made during the review without ending up with a butchered design. Thus, the review process has been suspended as to not block the queue for too long. This also means that review can start on the next proposal immediately. From the records, std.uuid would be next – are we good to go, Johannes? Other suggestions? Give me a day or two. A recent change to dmd/phobos broke some of the unittests, I'll fix those first. Ok, everything's working now (thanks to the folks in D.learn). Here's a copy of the mail I sent to the phobos list some weeks ago: About std.uuid (copied from the module documentation): - This is a port of boost.uuid from the boost project with some minor additions and API changes for a more D-like API. A UUID, or Universally unique identifier, is intended to uniquely identify information in a distributed environment without significant central coordination. It can be used to tag objects with very short lifetimes, or to reliably identify very persistent objects across a network. UUIDs have many applications. [...] - Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html Note: The code and documentation for sha1UUID has already been written, but until phobos has support for SHA1, that can't be included. The code is currently commented out in the source file (it's well tested with some 3rd party SHA1 code), but the documentation for those functions is included in the API-docs. I think those functions should be reviewed as well, so that it's possible to add them to phobos with a simple pull request at a later date. Note2: std.uuid also needs this pull request: https://github.com/D-Programming-Language/phobos/pull/398 It adds a isRandomNumberGenerator template to detect if a template parameter is a random-number generator type.
Re: Pegged: Syntax Highlighting
On 3/14/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: how would one use a parser like Pegged for syntax highlighting? Ok, typically one would use a lexer and not a parser. But using a parser might be more interesting for creating more complex syntax highlighting. :)
Re: Pegged: Syntax Highlighting
On 3/14/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 3/14/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: how would one use a parser like Pegged for syntax highlighting? Ok, typically one would use a lexer and not a parser. But using a parser might be more interesting for creating more complex syntax highlighting. :) Actually I think I can use the new ddmd-clean port for just this purpose. Sorry for the noise.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 03/13/2012 03:15 PM, Nick Sabalausky wrote: That's not even an accurate comparison anyway. Disabling CSS never does much to improve things, and usually it'll just make things *far* worse. I disable CSS frequently in Mozilla: View - Page Style - No Style. This fixes a lot of annoying styles that don't respect my font settings or don't display well based on the width of my browser screen.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On 03/13/12 23:24, Vladimir Panteleev wrote: On Tuesday, 13 March 2012 at 10:09:55 UTC, FeepingCreature wrote: However, there is a method to turn a signal handler into a regular function call that you can throw from. Very nice! The only similarity with a buffer overflow exploit is that we're overriding the continuation address. There is no execution of data, so it's closer to a return-to-libc attack. Argh. Yeah, that's the one I was thinking of. Here's a D implementation without inline assembler. It's DMD-specific due to a weirdness of its codegen. http://dump.thecybershadow.net/20f792fa05c020e561137cfaf3d65d7a/sigthrow_32.d The 64-bit version is a hack, in that it clobbers the last word on the stack. If the exception was thrown right after a stack frame was created, things might go ugly. The same trick as in my 32-bit implementation (creating a new stack frame with an extern(C) helper) won't work here, and I don't know enough about x64 exception handling to know how to fix it. http://dump.thecybershadow.net/121efc460a01fb4597926ec76352a674/sigthrow_64.d Sweet. Yeah, I think you need to use naked and reconstruct the stackframe. Not sure how it'd look; I'm not familiar with the x86_64 ABI. I think something like this needs to end up in Druntime, at least for Linux x86 and x64. Would be nice. I mean, Windows already has segfault-as-exception, doesn't it? It's only fair :)
Re: Has Tomasz's (h3r3tic's) OpenGL font rendering code been ported to D2?
On 03/12/12 10:42, Jacob Carlborg wrote: On 2012-03-11 23:36, Chad J wrote: I did some font rendering in C# using FreeType and OpenGL for a simple game. I can't remembering it being that hard. FreeType is not a C# library. FreeType is a C library. If this was easy for you, it was due to whatever C# wrapper you used.
Re: toHash = pure, nothrow, const, @safe
On 13 March 2012 04:15, H. S. Teoh hst...@quickfur.ath.cx wrote: On Mon, Mar 12, 2012 at 07:06:51PM -0700, Walter Bright wrote: On 3/12/2012 6:40 PM, H. S. Teoh wrote: And I'm not talking about doing just toHash, or just toString either. Any of these functions have complex interdependencies with each other, so it's either fix them ALL, or not at all. Yup. It also seems very hard to figure out a transitional path to it. Perhaps we just need to bite the bullet and do it all in one shot and check it into master, then deal with the aftermath later. :-) Otherwise it will simply never get off the ground. MMMmmm, now we're talking! I've always preferred this approach :P
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
I'm encouraged to see that every person in this thread so far seems to feel the same way as me regarding the syntax. On 14 March 2012 05:25, Derek Parnell ddparn...@bigpond.com wrote: On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox kevincox...@gmail.com wrote: (int i,,float f) = intBoringFloat(); For what its worth, the Euphoria Programming Language uses ? to signify ignored values. Yeah I tend to agree with that logic. I was quite liking the '_' that someone suggested much earlier in the thread: «x, _, int y» = intBoringFloat (); // Note: it seems to be unclear which brackets to use ;) Hey, the Japanese have some really cool brackets! 「x, _, int y」 = ... 〖x, _, int y〗 = ... 〘x, _, int y〙 = ... Tight! ;)
Re: Has Tomasz's (h3r3tic's) OpenGL font rendering code been ported to D2?
On 2012-03-14 09:03, FeepingCreature wrote: On 03/12/12 10:42, Jacob Carlborg wrote: On 2012-03-11 23:36, Chad J wrote: I did some font rendering in C# using FreeType and OpenGL for a simple game. I can't remembering it being that hard. FreeType is not a C# library. FreeType is a C library. If this was easy for you, it was due to whatever C# wrapper you used. I know it's a C library. As far as I know it was as similar to the C library as C# allows. I used guides and documentation written for the C library. -- /Jacob Carlborg
Re: Wanted: 128 bit integers
On 14 March 2012 02:37, Alex Rønne Petersen xtzgzo...@gmail.com wrote: On 14-03-2012 01:34, Paul D. Anderson wrote: I'm working on a decimal arithmetic project and I need 128 bit integers in order to implement the decimal128 type. (The decimal value is stored in 128 bits; the coefficient field is 114 bits, to hold values with 34 decimal digits.) I could use BigInt (but that's overkill) or I could code them up myself, which I'm willing to do if no alternative exists. But surely someone has already created this type, either as part of a larger project or as some kind of test problem, etc. Or perhaps someone would like to tackle it as a project of their own. I specifically need unsigned 128 bit integers, but both signed and unsigned versions would probably have more general applications. Better yet, if it checked for overflow, like Andrei's CheckedInt class in TDPL, it would be more immediately useful. This could also be the basis for a general fixed-size integer type, where the size is specified: CheckedInt!128, CheckedInt!96, etc. I recall having seen something like this mentioned in this forum. So has anyone already done this? Does anyone want to take it on? Thanks, Paul The D language specifies 128-bit integers: cent and ucent. They just aren't implemented yet... Why aren't they implemented in a library for the time being at least, so code can compile and work?
Re: [draft] New std.regex walkthrough
On 14.03.2012 0:32, Brad Anderson wrote:
On Tue, Mar 13, 2012 at 1:27 PM, Dmitry Olshansky dmitry.o...@gmail.com
mailto:dmitry.o...@gmail.com wrote:
For a couple of releases we have a new revamped std.regex, that as
far as I'm concerned works nicely, thanks to my GSOC commitment last
summer. Yet there was certain dark trend around std.regex/std.regexp
as both had severe bugs, missing documentation and what not, enough
to consider them unusable or dismiss prematurely.
It's about time to break this gloomy aura, and show that std.regex
is actually easy to use, that it does the thing and has some nice
extras.
Link: http://blackwhale.github.com/__regular-expression.html
http://blackwhale.github.com/regular-expression.html
Comments are welcome from experts and newbies alike, in fact it
should encourage people to try out a few tricks ;)
This is intended as replacement for an article on dlang.org
http://dlang.org
about outdated (and soon to disappear) std.regexp:
http://dlang.org/regular-__expression.html
http://dlang.org/regular-expression.html
[Spoiler] one example relies on a parser bug being fixed (blush):
https://github.com/D-__Programming-Language/phobos/__pull/481
https://github.com/D-Programming-Language/phobos/pull/481
Well, it was a specific lookahead inside lookaround so that's not
severe bug ;)
P.S. I've been following through a bunch of new bug reports
recently, thanks to everyone involved :)
--
Dmitry Olshansky
Second paragraph:
- ..,expressions, though one though one should... has too many though
ones
Third paragraph:
- ...keeping it's implementation... should be its
- We'll see how close to built-ins one can get this way. was kind of
confusing. I'd consider just doing away with the distinction between
built in and non-built in regex since it's an implementation detail most
programmers who use it don't even need to know about. Maybe say that it
is not built in and explain why that is a neat thing to have (meaning,
the language itself is powerful enough to express it in user code).
Yeah, the point about built-in vs library is kind of dangling in the air
for now. Will see how to wrap it up.
Fourth paragraph:
- ...article you'd have... should probably be you'll or, preferably,
you will.
- ...utilize it's API... should be its
- yet it's not required to get an understanding of the API. I'd
probably change this to ...yet it's not required to understand the API
Lost track of which paragraph:
- ... that allows writing a regex pattern in it's natural notation
another its
- trying to match special characters like I'd write trying to match
special regex characters like for clarity
- over input like e.g. search or simillar I'd remove the e.g., write
search as search() to show it's a function in other languages and fix
the spelling of similar :P
- An element type is Captures for the string type being used, it is a
random access range. I just found this confusing. Not sure what it's
trying to say.
- I won't go into full detail of the range conception, suffice to say,
I'd change conception to concept and remove suffice to say. (It's
a shame we don't a range article we can link to).
- At that time ancors like misspelled anchors
All to the point and fixed.
- Needless to say, one need not I'd remove the Needless to say,
because I think it's actually important to say :P
It's not important, as it has no effect on matching if there no anchors.
It's just cleaner to the reader, because it alerts along the way of hm,
this guy don't know what multi-line is, let's stay sharp and watch out
for other problems.
- replace(text, regex(r([0-9]{1,2})/([0-9]{1,2})/([0-9]{4}),g),
--); Is this code example correct? It references $1, $2, etc. in the
explanatory paragraph below but they are no where to be found.
Damnable DDoc ate my dollars!
And that's inside source code section, any ideas on how to avoid this mess?
- When you are explaining named captures it sounds like you are about to
show them in the subsequent code example but you are actually showing
what it'd look like without them which was a bit confusing.
- Maybe some more words on what lookaround/lookahead do as I was lost.
- Amdittedly, barrage of ? and ! makes regex rather obscure, more then
it's actually is. However should be Admittedly, the barrage of ? and !
makes the regex rather obscure, more than it actually is.. Maybe
change obscure to a different adjective. Perhaps complex looking or
complicated. (note I've removed the However as the upcoming sentence
isn't contradicting what you just said.
- Needless to say it's, again, I think it's rather important to say :P
Here I concur ;)
- Run-time version took around 10-20us on my machine, admittedly no
statistics. here, borrow this µ :P. Also, I'd get rid of admittedly
no statistics.
- meaningful tasks, it's features another its
- together it's major and another :P
Re: Replacing AA's in druntime
On 14.03.2012 6:39, Jakob Bornecrantz wrote: On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote: Hi all, My AA implementation is slowly inching closer to being ready to replace aaA.d. So far I've been writing the implementation outside of object_.d for ease of testing development; now I'm ready to start moving stuff into object_.d to start working on integration with druntime. Hi, If I'm understanding this correctly you are moving the entire implementation of the AA into object.d and as such letting programs be purview to its inner working? In sort meaning you are making the entire AA implementation D ABI locked. This will make it impossible to either change the AA implementation in any ABI breaking fashion or make it impossible to pass AA's between libraries compiled against different versions of druntime. I will just point out that the major point of ABI is to make sure different D compiler produce compatible object code. Thus it makes AA implementation locked already anyway, right? Is this what we really want? Cheers, Jakob. -- Dmitry Olshansky
Re: toHash = pure, nothrow, const, @safe
On 14.03.2012 3:23, Walter Bright wrote: On 3/13/2012 4:15 AM, Don Clugston wrote: On 13/03/12 03:05, Walter Bright wrote: On 3/12/2012 6:15 PM, Stewart Gordon wrote: And what about toString? Good question. What do you suggest? Why can't we just kill that abomination? Break a lot of existing code? And gain efficiency. BTW transition paths were suggested, need to just dig up DIP9 discussions. -- Dmitry Olshansky
Re: [draft] New std.regex walkthrough
On 14.03.2012 0:54, H. S. Teoh wrote: On Tue, Mar 13, 2012 at 11:27:57PM +0400, Dmitry Olshansky wrote: For a couple of releases we have a new revamped std.regex, that as far as I'm concerned works nicely, thanks to my GSOC commitment last summer. Yet there was certain dark trend around std.regex/std.regexp as both had severe bugs, missing documentation and what not, enough to consider them unusable or dismiss prematurely. It's about time to break this gloomy aura, and show that std.regex is actually easy to use, that it does the thing and has some nice extras. Link: http://blackwhale.github.com/regular-expression.html Comments are welcome from experts and newbies alike, in fact it should encourage people to try out a few tricks ;) [...] Yay! Updated docs is always a good thing. I'd like to do some copy-editing to make it nicer to read. (Hope you don't mind my extensive revisions, I'm trying to make the docs as professional as possible.) My revisions are in straight text under the quoted sections, and inline comments are enclosed in []. Introduction String processing is a kind of daily routine that most applications do in a one way or another. It should come as no wonder that many programming languages have standard libraries stoked with specialized functions for common needs. String processing is a common task performed by many applications. Many programming languages come with standard libraries that are equipped with a variety of functions for common string processing needs. I like equipped ;) The D programming language standard library among others offers a nice assortment in std.string and generic ones from std.algorithm. The D programming language standard library also offers a nice assortment of such functions in std.string, as well as generic functions in std.algorithm that can also work with strings. Still no amount of fixed functionality could cover all needs, as naturally flexible text data needs flexible solutions. Still no amount of predefined string functions could cover all needs. Text data is very flexible by nature, and so needs flexible solutions. Here is where regular expressions come in handy, often succinctly called as regexes. This is where regular expressions, or regexes for short, come in. Simple yet powerful language for defining patterns of strings, put together with a substitution mechanism, forms a Swiss Army knife of text processing. Regexes are a simple yet powerful language for defining patterns of strings, and when integrated with a substitution mechanism, forms a Swiss Army knife of text processing. It's considered so useful that a number of languages provides built-in support for regular expressions, though one though one should not jump to conclusion that built-in implies faster processing or more features. It's all about getting more convenient and friendly syntax for typical operations and usage patterns. It's considered so useful that a number of languages provides built-in support for regular expressions. (This doesn't necessarily mean, however, that built-in implies faster processing or more features. It's more a matter of providing a more convenient and friendly syntax for typical operations and usage patterns.) [I think it's better to put the second part in parentheses, since it's not really the main point of this doc.] I think putting that much in parens is a bad idea, but your wording is clearly superior. The D programming language provides a standard library module std.regex. [OK] Being a highly expressive systems language, it opens a possibility to get a good look and feel via core features, while keeping it's implementation within the language. Being a highly expressive systems language, D allows regexes to be implemented within the language itself, yet still have the same level of readability and usability that a built-in implementation would provide. Nice! We'll see how close to built-ins one can get this way. We will see below how close to built-in regexes we can achieve. By the end of article you'd have a good understanding of regular expression capabilities in this library, and how to utilize it's API in a most straightforward way. By the end of this article, you will have a good understanding of the regular expression capabilities offered by this library, and how to utilize its API in the most straightforward way. Examples in this article assume the reader has fairly good understanding of regex elements, yet it's not required to get an understanding of the API. Examples in this article assume that the reader has fairly good understanding of regex elements, but this is not required to get an understanding of the API. [I'll do this much for now. More to come later.] Thanks. -- Dmitry Olshansky
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 13/03/2012 23:24, Vladimir Panteleev a écrit : On Tuesday, 13 March 2012 at 10:09:55 UTC, FeepingCreature wrote: However, there is a method to turn a signal handler into a regular function call that you can throw from. Very nice! The only similarity with a buffer overflow exploit is that we're overriding the continuation address. There is no execution of data, so it's closer to a return-to-libc attack. This is a very clean (and Neat) solution. Here's a D implementation without inline assembler. It's DMD-specific due to a weirdness of its codegen. http://dump.thecybershadow.net/20f792fa05c020e561137cfaf3d65d7a/sigthrow_32.d The 64-bit version is a hack, in that it clobbers the last word on the stack. If the exception was thrown right after a stack frame was created, things might go ugly. The same trick as in my 32-bit implementation (creating a new stack frame with an extern(C) helper) won't work here, and I don't know enough about x64 exception handling to know how to fix it. http://dump.thecybershadow.net/121efc460a01fb4597926ec76352a674/sigthrow_64.d I think something like this needs to end up in Druntime, at least for Linux x86 and x64. You are loosing EAX in the process.
Re: Optimize away immediately-called delegate literals?
On Mon, 12 Mar 2012 20:28:15 -0400, H. S. Teoh hst...@quickfur.ath.cx
wrote:
Hmph.
I tried this code:
import std.stdio;
struct A {
int[] data;
int opApply(int delegate(ref int) dg) {
foreach (d; data) {
if (dg(d)) return 1;
}
return 0;
}
}
void main() {
A a;
int n = 0;
a.data = [1,2,3,4,5];
foreach (d; a) {
n++;
}
}
With both dmd and gdc, the delegate is never inlined. :-( Compiling
with gdc -O3 causes opApply to get inlined and loop-unrolled, but the
call to the delegate is still there. With dmd -O, even opApply is not
inlined, and the code is generally much longer per loop iteration than
gdc -O3.
IIRC, ldc does inline opApply. But this is somewhat hearsay since I don't
use ldc. I'm just remembering what others have posted here.
-Steve
Re: Negative integer modulo/division
On Tue, 13 Mar 2012 15:13:01 -0400, bearophile bearophileh...@lycos.com wrote: For the modulus I sometimes use: ((x % y) + y) % y This might be more efficient (assuming z is your target for this): if((z = x % y) 0) z += y; Though I don't know, maybe the optimizer will reduce to this. Hard to do it in a single expression without using a function. -Steve
Re: Arbitrary abbreviations in phobos considered ridiculous
On Mon, 12 Mar 2012 20:50:38 -0400, Era Scarecrow rtcv...@yahoo.com wrote: Let's assume you make a site for power users, those who want to buy computer parts and books and related stuff like that. Now if you require JS to have it run, and all the power users refuse to use JS, you've just killed all your customers. a 6 Million customers with orders which could get hundreds of millions of dollars, lost because a non-JS wasn't offered. Don't know about you, but 6 millions people could make or break your business (Just my opinion). All the arguments that say you shouldn't require javascript seem to center around some estimated (and frankly, wildly exaggerated) number of people who have disabled javascript *and* won't turn it on to use a specific site. It seems you all have ignored or discredited the data I quoted which is *actual measured data*. If we can't agree on facts, it seems we can't really have a rational argument, so I'll respectfully step away from this. -Steve
Re: toHash = pure, nothrow, const, @safe
In general, for modules a and b, all of these should work: dmd a b dmd b a dmd -c a dmd -c b For '-c' CTFE will already run semantic3 on the other module's functions. But it would be very inefficient to do that for attributes.
Re: toHash = pure, nothrow, const, @safe
On Tue, 13 Mar 2012 12:03:22 -0400, Alex Rønne Petersen xtzgzo...@gmail.com wrote: Yes, and in some cases, it doesn't even work right; i.e. you can declare certain opCmp and opEquals signatures that work fine for ==, , , etc but don't get emitted to the TypeInfo metadata, and vice versa. It's a mess. See my post in this thread. It fixes this problem. -Steve
Re: toHash = pure, nothrow, const, @safe
On Mon, 12 Mar 2012 22:06:51 -0400, Walter Bright newshou...@digitalmars.com wrote: On 3/12/2012 6:40 PM, H. S. Teoh wrote: And I'm not talking about doing just toHash, or just toString either. Any of these functions have complex interdependencies with each other, so it's either fix them ALL, or not at all. Yup. It also seems very hard to figure out a transitional path to it. It seems most people have ignored my post in this thread, so I'll say it again: What about an annotation (I suggested @type, it could be anything, but I'll use that as my strawman) that says to the compiler this is part of the TypeInfo_Struct interface. In essence, when @type is encountered the compiler looks at TypeInfo_Struct (in object.di) for the equivalent xfuncname. Then uses the attributes of that function pointer (and also the parameter types/count) to compile the given method. It does two things: 1. It provides an indicator a user can use when he *wants* to include that function as part of the typeinfo. Right now, you have to guess, and pray to the compiler gods that your function signature is deemed worthy. 2. It takes all sorts of burden off the compiler to know which functions are special, and to make assumptions about them. We can implement it now *without* making those function pointers pure/safe/nothrow/whatever, and people can then experiment with changing it without having to muck with the compiler. As a bonus, it also allows people to experiment with adding more interface methods to structs without having to muck with the compiler. The only drawback is what to do with existing code that *doesn't* have @type on it's functions that go into TypeInfo_Struct. There are ways to handle this. My suggestion is to simply treat the current methods as special and assume @type is on those methods. But I would suggest removing that hack in the future, with some way to easily tell you where you need to put @type annotations. -Steve
Re: toHash = pure, nothrow, const, @safe
On Tue, 13 Mar 2012 19:23:25 -0400, Walter Bright newshou...@digitalmars.com wrote: On 3/13/2012 4:15 AM, Don Clugston wrote: On 13/03/12 03:05, Walter Bright wrote: On 3/12/2012 6:15 PM, Stewart Gordon wrote: And what about toString? Good question. What do you suggest? Why can't we just kill that abomination? Break a lot of existing code? I'm unaware of much code that uses TypeInfo.xtostring to print anything. write[f][ln] doesn't, and I don't think std.conv.to does either. In other words, killing the specialness of toString doesn't mean killing toString methods in all structs. What this does is allow us to not worry about what you annotate your toString methods with, it just becomes a regular method. -Steve
Re: toHash = pure, nothrow, const, @safe
On 14.03.2012 16:11, Steven Schveighoffer wrote: On Mon, 12 Mar 2012 22:06:51 -0400, Walter Bright newshou...@digitalmars.com wrote: On 3/12/2012 6:40 PM, H. S. Teoh wrote: And I'm not talking about doing just toHash, or just toString either. Any of these functions have complex interdependencies with each other, so it's either fix them ALL, or not at all. Yup. It also seems very hard to figure out a transitional path to it. It seems most people have ignored my post in this thread, so I'll say it again: What about an annotation (I suggested @type, it could be anything, but I'll use that as my strawman) that says to the compiler this is part of the TypeInfo_Struct interface. In essence, when @type is encountered the compiler looks at TypeInfo_Struct (in object.di) for the equivalent xfuncname. Then uses the attributes of that function pointer (and also the parameter types/count) to compile the given method. It does two things: 1. It provides an indicator a user can use when he *wants* to include that function as part of the typeinfo. Right now, you have to guess, and pray to the compiler gods that your function signature is deemed worthy. 2. It takes all sorts of burden off the compiler to know which functions are special, and to make assumptions about them. We can implement it now *without* making those function pointers pure/safe/nothrow/whatever, and people can then experiment with changing it without having to muck with the compiler. As a bonus, it also allows people to experiment with adding more interface methods to structs without having to muck with the compiler. The only drawback is what to do with existing code that *doesn't* have @type on it's functions that go into TypeInfo_Struct. There are ways to handle this. My suggestion is to simply treat the current methods as special and assume @type is on those methods. But I would suggest removing that hack in the future, with some way to easily tell you where you need to put @type annotations. For one, I'm sold on it. And the proposed magic hack can work right now, then it'll just get deprecated in favor of explicit @type. -- Dmitry Olshansky
Re: Negative integer modulo/division
On 14/03/2012 11:27, Steven Schveighoffer wrote: snip This might be more efficient (assuming z is your target for this): if((z = x % y) 0) z += y; snip Depends on what you want it to do if y is negative. In such cases, what you've got here will return a value in (y, 0] if x is positive, or in (2*y, y] if x is negative. I too wish D gave the choice between floor-mod and trunc-mod. Stewart.
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On Wednesday, 14 March 2012 at 02:33:29 UTC, Kevin Cox wrote: Kind of unrelated but I think that it is important to have a way to ignore values also. Leaving them bank would sufice. (int i,,float f) = intBoringFloat(); or (int i, null, float f) = intBoringFloat(); or (int i, void, float f) = intBoringFloat();
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On Wed, 14 Mar 2012 03:52:55 -0500, Manu turkey...@gmail.com wrote: I'm encouraged to see that every person in this thread so far seems to feel the same way as me regarding the syntax. On 14 March 2012 05:25, Derek Parnell ddparn...@bigpond.com wrote: On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox kevincox...@gmail.com wrote: (int i,,float f) = intBoringFloat(); For what its worth, the Euphoria Programming Language uses ? to signify ignored values. Yeah I tend to agree with that logic. I was quite liking the '_' that someone suggested much earlier in the thread: «x, _, int y» = intBoringFloat (); // Note: it seems to be unclear which brackets to use ;) Hey, the Japanese have some really cool brackets! 「x, _, int y」 = ... 〖x, _, int y〗 = ... 〘x, _, int y〙 = ... Tight! ;) UTF math has a bunch of cool brackets as well ⟦ x, _, int y ⟧ ⦃ x, _, int y ⦄ ⦅ x, _, int y ⦆ ⦇ x, _, int y ⦈ ⦉ x, _, int y ⦊ But there's a reason we use /// instead of ⫻; we shouldn't require custom keyboard mappings in order to program efficiently in D.
Re: toHash = pure, nothrow, const, @safe
In essence, when @type is encountered the compiler looks at TypeInfo_Struct (in object.di) for the equivalent xfuncname. Then uses the attributes of that function pointer (and also the parameter types/count) to compile the given method. Why would you want to add explicit annotation for implicit TypeInfo_Struct methods? I think @type is a very interesting idea if combined with a string-method lookup in TypeInfo_Struct, but this wouldn't allow for static type checking. If you wanted static type checking then @type could probably refer to Interfaces.
Re: Fortran DLL and D
On 03/13/2012 05:15 PM, Michael wrote:
Hi everyone)
dmd 2.058
os: win 7 64 bit
fortran compilers: gfortran, ftn95
Here's apples to oranges, since I'm on linux 64 bit, but with your code
and this:
pragma(lib, flib);
extern(C) void fsu_(int*i);
void main(){
int i = 1;
fsu_(i);
}
when compiled on my box gives
The answer is x = 2.5004E-02 1
If something similar doesn't work for you, can you post disassembly
dumps of your dll function and calling function?
Re: toHash = pure, nothrow, const, @safe
On Wed, 14 Mar 2012 09:27:08 -0400, Martin Nowak d...@dawgfoto.de wrote: In essence, when @type is encountered the compiler looks at TypeInfo_Struct (in object.di) for the equivalent xfuncname. Then uses the attributes of that function pointer (and also the parameter types/count) to compile the given method. Why would you want to add explicit annotation for implicit TypeInfo_Struct methods? Because right now, it's a guessing game of whether you wanted an operation to be part of the typeinfo's interface. And many times, the compiler guesses wrong. I've seen countless posts on d.learn saying why won't AA's call my opEquals or opHash function? With explicit annotation, you have instructed the compiler I expect this to be in TypeInfo, so it can take the appropriate actions if it doesn't match. I think @type is a very interesting idea if combined with a string-method lookup in TypeInfo_Struct, but this wouldn't allow for static type checking. Yes it would. It has access to TypeInfo_Struct in object.di, so it can figure out what the signature should be. -Steve
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On 03/14/12 12:13, deadalnix wrote: Le 13/03/2012 23:24, Vladimir Panteleev a écrit : I think something like this needs to end up in Druntime, at least for Linux x86 and x64. You are loosing EAX in the process. It's somewhat unavoidable. One way or another, you need to find _some_ threadlocal spot to stick those extra size_t.sizeof bytes, since you mustn't lose data, but the hack works by _overwriting_ the return address.
Re: Replacing AA's in druntime
On 14/03/12 03:39, Jakob Bornecrantz wrote: On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote: Hi all, My AA implementation is slowly inching closer to being ready to replace aaA.d. So far I've been writing the implementation outside of object_.d for ease of testing development; now I'm ready to start moving stuff into object_.d to start working on integration with druntime. Hi, If I'm understanding this correctly you are moving the entire implementation of the AA into object.d and as such letting programs be purview to its inner working? In sort meaning you are making the entire AA implementation D ABI locked. This will make it impossible to either change the AA implementation in any ABI breaking fashion or make it impossible to pass AA's between libraries compiled against different versions of druntime. Much less so than the existing AA implementation.
Re: Replacing AA's in druntime
On Tue, 13 Mar 2012 22:39:25 -0400, Jakob Bornecrantz wallbra...@gmail.com wrote: On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote: Hi all, My AA implementation is slowly inching closer to being ready to replace aaA.d. So far I've been writing the implementation outside of object_.d for ease of testing development; now I'm ready to start moving stuff into object_.d to start working on integration with druntime. Hi, If I'm understanding this correctly you are moving the entire implementation of the AA into object.d and as such letting programs be purview to its inner working? In sort meaning you are making the entire AA implementation D ABI locked. This will make it impossible to either change the AA implementation in any ABI breaking fashion or make it impossible to pass AA's between libraries compiled against different versions of druntime. Is this what we really want? This is unavoidable, whether it's a template or not. What changes do you envision would be transparent using an opaque pImpl model (as was done in previous versions of phobos), but would break using templates? -Steve
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no?
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote: Sweet. Yeah, I think you need to use naked and reconstruct the stackframe. Not sure how it'd look; I'm not familiar with the x86_64 ABI. I think it might be safe to just reconstruct the stack frame in the signal handler, and set gregs[REG_EIP] to _d_throw directly. It should also use a pre-allocated exception object (like how it's done with OutofMemoryError and InvalidMemoryOperationError), in case there's data corruption in the GC.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 17:08, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no? You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 17:34, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote: Sweet. Yeah, I think you need to use naked and reconstruct the stackframe. Not sure how it'd look; I'm not familiar with the x86_64 ABI. I think it might be safe to just reconstruct the stack frame in the signal handler, and set gregs[REG_EIP] to _d_throw directly. It should also use a pre-allocated exception object (like how it's done with OutofMemoryError and InvalidMemoryOperationError), in case there's data corruption in the GC. Especially if the signal is sent because of stack overflow !
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 14:43, FeepingCreature a écrit : On 03/14/12 12:13, deadalnix wrote: Le 13/03/2012 23:24, Vladimir Panteleev a écrit : I think something like this needs to end up in Druntime, at least for Linux x86 and x64. You are loosing EAX in the process. It's somewhat unavoidable. One way or another, you need to find _some_ threadlocal spot to stick those extra size_t.sizeof bytes, since you mustn't lose data, but the hack works by _overwriting_ the return address. Thread local storage is a very easy thing in D. Can't we just use a static variable and set from within the signal handler ?
Re: Wanted: 128 bit integers
On Wednesday, March 14, 2012 10:57:03 Manu wrote: On 14 March 2012 02:37, Alex Rønne Petersen xtzgzo...@gmail.com wrote: On 14-03-2012 01:34, Paul D. Anderson wrote: The D language specifies 128-bit integers: cent and ucent. They just aren't implemented yet... Why aren't they implemented in a library for the time being at least, so code can compile and work? I believe that what it really comes down to is that cent and ucent were set aside just in case they would be needed with no specific plans to do anything with them. So, they'll probably be implemented eventually, but they're definitely not a priority. And if you really need larger integers, then there's BigInt. Prior to the 64-bit ports of dmd (which are fairly recent), dmd wasn't even on any architectures that supported 128 bit integers anyway. - Jonathan M Davis
Re: Wanted: 128 bit integers
Jonathan M Davis: Prior to the 64-bit ports of dmd (which are fairly recent), dmd wasn't even on any architectures that supported 128 bit integers anyway. You are able to support 128 bit numbers even on a 16 bit system :-) Bye, bearophile
Re: Wanted: 128 bit integers
On 14-03-2012 17:49, Jonathan M Davis wrote: On Wednesday, March 14, 2012 10:57:03 Manu wrote: On 14 March 2012 02:37, Alex Rønne Petersenxtzgzo...@gmail.com wrote: On 14-03-2012 01:34, Paul D. Anderson wrote: The D language specifies 128-bit integers: cent and ucent. They just aren't implemented yet... Why aren't they implemented in a library for the time being at least, so code can compile and work? I believe that what it really comes down to is that cent and ucent were set aside just in case they would be needed with no specific plans to do anything with them. So, they'll probably be implemented eventually, but they're definitely not a priority. And if you really need larger integers, then there's BigInt. Prior to the 64-bit ports of dmd (which are fairly recent), dmd wasn't even on any architectures that supported 128 bit integers anyway. - Jonathan M Davis There aren't really any platforms that natively support 128-bit integers, even today. The most support you'll get is SIMD-like extensions, but those aren't necessarily useful for implementing 128-bit integers. So, most likely, the compiler would just have to unroll 128-bit operations just as it does for 64-bit operations on 32-bit targets. -- - Alex
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wednesday, 14 March 2012 at 16:39:29 UTC, deadalnix wrote: Le 14/03/2012 17:34, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote: Sweet. Yeah, I think you need to use naked and reconstruct the stackframe. Not sure how it'd look; I'm not familiar with the x86_64 ABI. I think it might be safe to just reconstruct the stack frame in the signal handler, and set gregs[REG_EIP] to _d_throw directly. It should also use a pre-allocated exception object (like how it's done with OutofMemoryError and InvalidMemoryOperationError), in case there's data corruption in the GC. Especially if the signal is sent because of stack overflow ! Not sure if sarcasm..? In case of a stack overflow, you can't call _d_throwc (or use the throw statement) anyway.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote: Le 14/03/2012 17:08, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no? You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example. This doesn't have anything to do with turning signals into exceptions.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wed, Mar 14, 2012 at 05:39:38PM +0100, deadalnix wrote: Le 14/03/2012 17:08, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no? You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example. I believe the original purpose of this was to catch SIGSEGV and turn it into a thrown Error. So we don't care whether EAX is overwritten since we're never going to return to the code that caused the SEGV; we're just reconstructing the stack frame so that stack unwinding will work correctly when we throw the Error. T -- People tell me that I'm skeptical, but I don't believe it.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 18:00, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote: Le 14/03/2012 17:08, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no? You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example. This doesn't have anything to do with turning signals into exceptions. No but this does, make sense to catch segfault and act according to it to implement such a functionality. This is a very close problem.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote: Le 14/03/2012 18:00, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote: Le 14/03/2012 17:08, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no? You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example. This doesn't have anything to do with turning signals into exceptions. No but this does, make sense to catch segfault and act according to it to implement such a functionality. This is a very close problem. You can't resume D exceptions.
Implicit string lit conversion to wstring/dstring
Code:
import std.stdio;
version(explicit) {
void func(dstring s) {
dstring t = s;
writeln(t);
}
} else {
void func(S)(S s) {
dstring t = s; // line 10
writeln(t);
}
}
void main() {
func(abc);
}
If version=explicit is set, the program compiles fine. But if not, then
the compiler complains:
test.d:10: Error: cannot implicitly convert expression (s) of type
string to immutable(dchar)[]
What do I need to do to make the template version of func trigger
implicit conversion of the string lit to dstring? What I'm trying to do
is to templatize dstring as well, but still benefit from the
string-dstring conversion when instantiated with dstring.
(Ditto with implicit conversion to wstring.)
T
--
He who laughs last thinks slowest.
Re: Implicit string lit conversion to wstring/dstring
On 14-03-2012 19:00, H. S. Teoh wrote:
Code:
import std.stdio;
version(explicit) {
void func(dstring s) {
dstring t = s;
writeln(t);
}
} else {
void func(S)(S s) {
dstring t = s; // line 10
writeln(t);
}
}
void main() {
func(abc);
}
If version=explicit is set, the program compiles fine. But if not, then
the compiler complains:
test.d:10: Error: cannot implicitly convert expression (s) of type
string to immutable(dchar)[]
What do I need to do to make the template version of func trigger
implicit conversion of the string lit to dstring? What I'm trying to do
is to templatize dstring as well, but still benefit from the
string-dstring conversion when instantiated with dstring.
(Ditto with implicit conversion to wstring.)
T
I doubt that such an implicit conversion even exists. You have to prefix
the string appropriately, e.g.:
string s = foo;
wstring w = wbar;
dstring d = dbaz;
--
- Alex
Re: Implicit string lit conversion to wstring/dstring
On 14-03-2012 19:00, Alex Rønne Petersen wrote:
On 14-03-2012 19:00, H. S. Teoh wrote:
Code:
import std.stdio;
version(explicit) {
void func(dstring s) {
dstring t = s;
writeln(t);
}
} else {
void func(S)(S s) {
dstring t = s; // line 10
writeln(t);
}
}
void main() {
func(abc);
}
If version=explicit is set, the program compiles fine. But if not, then
the compiler complains:
test.d:10: Error: cannot implicitly convert expression (s) of type
string to immutable(dchar)[]
What do I need to do to make the template version of func trigger
implicit conversion of the string lit to dstring? What I'm trying to do
is to templatize dstring as well, but still benefit from the
string-dstring conversion when instantiated with dstring.
(Ditto with implicit conversion to wstring.)
T
I doubt that such an implicit conversion even exists. You have to prefix
the string appropriately, e.g.:
string s = foo;
wstring w = wbar;
dstring d = dbaz;
Sorry, I lied. Like this:
string s = fooc; (the c is optional)
wstring w = barw;
dstring d = bazd;
See: http://dlang.org/lex.html
--
- Alex
Re: Implicit string lit conversion to wstring/dstring
On Wed, Mar 14, 2012 at 07:00:35PM +0100, Alex Rønne Petersen wrote:
On 14-03-2012 19:00, H. S. Teoh wrote:
Code:
import std.stdio;
version(explicit) {
void func(dstring s) {
dstring t = s;
writeln(t);
}
} else {
void func(S)(S s) {
dstring t = s; // line 10
writeln(t);
}
}
void main() {
func(abc);
}
If version=explicit is set, the program compiles fine. But if not, then
the compiler complains:
test.d:10: Error: cannot implicitly convert expression (s) of type
string to immutable(dchar)[]
What do I need to do to make the template version of func trigger
implicit conversion of the string lit to dstring? What I'm trying to do
is to templatize dstring as well, but still benefit from the
string-dstring conversion when instantiated with dstring.
(Ditto with implicit conversion to wstring.)
T
I doubt that such an implicit conversion even exists. You have to
prefix the string appropriately, e.g.:
OK, maybe implicit conversion is the wrong word. The compiler is
obviously interpreting func(abc) as func(abcd) when we declare
func(dstring). But when we declare func(S)(S), the compiler deduces
abc as string and sets S=string.
What I want is to force the compiler to deduce S=dstring when I declare
func(S)(S) and call it as func(abc).
T
--
Дерево держится корнями, а человек - друзьями.
Re: Implicit string lit conversion to wstring/dstring
On 14-03-2012 19:16, H. S. Teoh wrote:
On Wed, Mar 14, 2012 at 07:00:35PM +0100, Alex Rønne Petersen wrote:
On 14-03-2012 19:00, H. S. Teoh wrote:
Code:
import std.stdio;
version(explicit) {
void func(dstring s) {
dstring t = s;
writeln(t);
}
} else {
void func(S)(S s) {
dstring t = s; // line 10
writeln(t);
}
}
void main() {
func(abc);
}
If version=explicit is set, the program compiles fine. But if not, then
the compiler complains:
test.d:10: Error: cannot implicitly convert expression (s) of type
string to immutable(dchar)[]
What do I need to do to make the template version of func trigger
implicit conversion of the string lit to dstring? What I'm trying to do
is to templatize dstring as well, but still benefit from the
string-dstring conversion when instantiated with dstring.
(Ditto with implicit conversion to wstring.)
T
I doubt that such an implicit conversion even exists. You have to
prefix the string appropriately, e.g.:
OK, maybe implicit conversion is the wrong word. The compiler is
obviously interpreting func(abc) as func(abcd) when we declare
func(dstring). But when we declare func(S)(S), the compiler deduces
abc as string and sets S=string.
What I want is to force the compiler to deduce S=dstring when I declare
func(S)(S) and call it as func(abc).
T
But then... why not just make it take a dstring? Maybe I'm not following
your intent here...
Anyway, what Phobos functions tend to do is to set S = string by default
and otherwise force people to either pass the string type *or* use the
string suffices.
--
- Alex
Re: Wanted: 128 bit integers
On Wednesday, March 14, 2012 17:51:49 Alex Rønne Petersen wrote: On 14-03-2012 17:49, Jonathan M Davis wrote: On Wednesday, March 14, 2012 10:57:03 Manu wrote: On 14 March 2012 02:37, Alex Rønne Petersenxtzgzo...@gmail.com wrote: On 14-03-2012 01:34, Paul D. Anderson wrote: The D language specifies 128-bit integers: cent and ucent. They just aren't implemented yet... Why aren't they implemented in a library for the time being at least, so code can compile and work? I believe that what it really comes down to is that cent and ucent were set aside just in case they would be needed with no specific plans to do anything with them. So, they'll probably be implemented eventually, but they're definitely not a priority. And if you really need larger integers, then there's BigInt. Prior to the 64-bit ports of dmd (which are fairly recent), dmd wasn't even on any architectures that supported 128 bit integers anyway. - Jonathan M Davis There aren't really any platforms that natively support 128-bit integers, even today. The most support you'll get is SIMD-like extensions, but those aren't necessarily useful for implementing 128-bit integers. So, most likely, the compiler would just have to unroll 128-bit operations just as it does for 64-bit operations on 32-bit targets. long long is 128 bits on 64-bit Linux. That's what I meant by support. 32-bit doesn't have that with any C type on any platform that I know of. I have no idea how it's implemented though. - Jonathan M Davis
Re: Implicit string lit conversion to wstring/dstring
On 14.03.2012 22:00, H. S. Teoh wrote:
Code:
import std.stdio;
version(explicit) {
void func(dstring s) {
dstring t = s;
writeln(t);
}
} else {
void func(S)(S s) {
dstring t = s; // line 10
writeln(t);
}
}
void main() {
func(abc);
}
If version=explicit is set, the program compiles fine. But if not, then
the compiler complains:
test.d:10: Error: cannot implicitly convert expression (s) of type
string to immutable(dchar)[]
What do I need to do to make the template version of func trigger
implicit conversion of the string lit to dstring? What I'm trying to do
is to templatize dstring as well, but still benefit from the
string-dstring conversion when instantiated with dstring.
(Ditto with implicit conversion to wstring.)
T
How about this (untested)?
void func()(dstring s) {
dstring t = s;
//... funcImpl(t);
}
void func(S)(S s) {
dstring t = to!dstring(s);
//... funcImpl(t);
}
--
Dmitry Olshansky
Re: Implicit string lit conversion to wstring/dstring
Alex Rønne Petersen xtzgzo...@gmail.com wrote in message news:jjqn9f$1iht$1...@digitalmars.com... But then... why not just make it take a dstring? Maybe I'm not following your intent here... Probably because then this becomes an error: string s = abc; func(s); It's an interesting problem. I'm not aware of a solution. I suppose you'd just have to make it take only dstring and then expect string/wstring vars to be handled by the caller like func(to!dstring(s))
Re: Implicit string lit conversion to wstring/dstring
Dmitry Olshansky dmitry.o...@gmail.com wrote in message
news:jjqnnj$1j86$1...@digitalmars.com...
How about this (untested)?
void func()(dstring s) {
dstring t = s;
//... funcImpl(t);
}
void func(S)(S s) {
dstring t = to!dstring(s);
//... funcImpl(t);
}
That fails to compile when passed a dstring because it matches both
functions. Adding an if(!is(S==dstring)) constraint to the second makes it
compile, but then func(abc) just calls the second one instead of the
first.
Re: Implicit string lit conversion to wstring/dstring
On Wed, 14 Mar 2012 14:16:11 -0400, H. S. Teoh hst...@quickfur.ath.cx wrote: What I want is to force the compiler to deduce S=dstring when I declare func(S)(S) and call it as func(abc). http://d.puremagic.com/issues/show_bug.cgi?id=4998 Please vote or contribute your thoughts. -Steve
Container templates and constancy of elements
With some containers, such as lists and trees (binary search trees aside), it doesn't matter if the elements can change state, since the data structure remains well-formed. However, with others, such as sets and AAs, it's desirable if the keys don't mutate. Any operations on them won't work right if there are keys in the wrong hash slots or out of order (depending on the underlying data structure) because they have changed since being put into the container. Of course, this doesn't apply to _values_ in an AA, since these can safely mutate. In Java and D1, it seems you just have to go on trust if you want your container to accept key types other than strict value types. But can we do better in D2 - short of forcing the key type to be immutable, which would hinder the container's usefulness? But it seems D2 has taken one step in that general direction by automatically tail-consting the key type of an AA. But it doesn't stop modifications to the key through mutable references to the data. And if the key is of class type, you can still modify the object, since D2 conflates constancy of an object reference with constancy of the object itself. This is in itself silly. Really, D should have tail-const built in for stuff like this. OK, so there's Rebindable, but I've found it to be a PITA when trying to do generic programming with it, as well as leading to this AA key anomaly because it isn't a built-in feature. I suppose there are a few possibilities for what constancy to apply to elements of a data structure to which changes might affect the structure's integrity: (a) force the type to be tail-const if it's an array, otherwise don't add any constancy (b) force the type to be tail-const if it's an array, or fully const if it's a class (c) force the type to be tail-immutable if it's an array, otherwise don't add any constancy (d) force the type to be tail-immutable if it's an array, or fully immutable if it's a class (e) don't add any constancy, but just rely on trust Currently, AAs implement (a). (d) guarantees that changes to the data that mess up the data structure will never happen, at least if the programmer doesn't bypass the const system. (e) is the route D1 and Java are forced to take. Am I right in thinking that sets and maps in the C++ STL take the same path? Anyway, what are people's thoughts on the right way to go here? Stewart.
Re: Implicit string lit conversion to wstring/dstring
On Wed, Mar 14, 2012 at 02:44:40PM -0400, Steven Schveighoffer wrote:
On Wed, 14 Mar 2012 14:16:11 -0400, H. S. Teoh
hst...@quickfur.ath.cx wrote:
What I want is to force the compiler to deduce S=dstring when I
declare func(S)(S) and call it as func(abc).
http://d.puremagic.com/issues/show_bug.cgi?id=4998
Please vote or contribute your thoughts.
[...]
Ahhh, thanks for pointing this out. That is exactly the problem I'm
struggling with.
I guess the motivation of my original question wasn't clear. I should
say that I ran into this problem in the context of my AA implementation.
I've successfully implemented Andrei's suggestion: int[wstring] will now
accept wchar[], const(wchar)[], in addition to wstring in .get,
.opIndex, etc.. It will implicitly call wchar[].idup when it needs to
create a new hash entry. (Ditto with dstring, and with any immutable
array key type.)
To implement this change, opIndexAssign now looks like this:
struct AssociativeArray(Key,Value) {
...
void opIndexAssign(K)(in Value v, in K key)
if (isCompatWithKey!K)
{
...
}
}
The template isCompatWithKey basically checks if K can be implicitly
converted to Key, or has an .idup method that returns something that can
be implicitly converted to Key.
However, this change broke this code:
AssociativeArray!(wstring,int) aa;
aa[abc] = 123;// error: compiler deduces K as string,
// so isCompatWithKey!K fails: string
// can't implicitly convert to wstring
Whereas before, when opIndexAssign looked like this:
void opIndexAssign(in Value v, in Key key)
{
...
}
everything worked, because the compiler deduces the type of abc as
wstring since Key==wstring.
Now you have to write:
aa[abcw] = 123;
which isn't the end of the world, I suppose, but it's not very nice, and
also breaks existing code that depended on the compiler automatically
deducing that typeof(abc)==wstring.
T
--
There are three kinds of people in the world: those who can count, and those
who can't.
Re: Multiple return values...
On 3/13/12 6:12 PM, Andrei Alexandrescu wrote: On 3/13/12 2:57 PM, Manu wrote: And you think that's more readable and intuitive than: (v1, v2, v3) = fun(); ? Yes (e.g. when I see the commas my mind starts running in all directions because that's valid code nowadays that ignores v1 and v2 and keeps v3 as an lvalue). Who uses that, except code generators? I'd like D to deprecate the comma so it can be used for other things, like tuple assignment. Let me put it another way: I don't see one syntax over another a deal maker or deal breaker. At all. Well, it's sad that syntax is not very important in D. If you have to write less code there will be less chance for bugs and it will be more understandable (unless you obfuscate the code, obviously). Here's what you can do in Ruby: a = 1 b = 2 # Swap the contents a, b = b, a Can you do something like that with templates in D, with a nice syntax?
Re: Multiple return values...
On 3/14/12 2:02 PM, Ary Manzana wrote: On 3/13/12 6:12 PM, Andrei Alexandrescu wrote: On 3/13/12 2:57 PM, Manu wrote: And you think that's more readable and intuitive than: (v1, v2, v3) = fun(); ? Yes (e.g. when I see the commas my mind starts running in all directions because that's valid code nowadays that ignores v1 and v2 and keeps v3 as an lvalue). Who uses that, except code generators? I'd like D to deprecate the comma so it can be used for other things, like tuple assignment. I'd like that, too, but we need to worry about breaking code, too. Let me put it another way: I don't see one syntax over another a deal maker or deal breaker. At all. Well, it's sad that syntax is not very important in D. That's an undue generalization of what I said. If you have to write less code there will be less chance for bugs and it will be more understandable (unless you obfuscate the code, obviously). I agree. Here's what you can do in Ruby: a = 1 b = 2 # Swap the contents a, b = b, a Can you do something like that with templates in D, with a nice syntax? swap(a, b) Andrei
Re: Implicit string lit conversion to wstring/dstring
On 3/14/12 2:01 PM, H. S. Teoh wrote:
However, this change broke this code:
AssociativeArray!(wstring,int) aa;
aa[abc] = 123; // error: compiler deduces K as string,
// so isCompatWithKey!K fails: string
// can't implicitly convert to wstring
Whereas before, when opIndexAssign looked like this:
void opIndexAssign(in Value v, in Key key)
{
...
}
everything worked, because the compiler deduces the type of abc as
wstring since Key==wstring.
Aha! This is one of those cases in which built-in magic smells of putrid
beef soup.
I think it's possible to still make this work by beefing up the template
constraints such that the working signature is selected for strings.
Andrei
Re: Container templates and constancy of elements
On Wed, Mar 14, 2012 at 06:51:54PM +, Stewart Gordon wrote: With some containers, such as lists and trees (binary search trees aside), it doesn't matter if the elements can change state, since the data structure remains well-formed. However, with others, such as sets and AAs, it's desirable if the keys don't mutate. Any operations on them won't work right if there are keys in the wrong hash slots or out of order (depending on the underlying data structure) because they have changed since being put into the container. Of course, this doesn't apply to _values_ in an AA, since these can safely mutate. IMO, AA keys should be *implicitly* immutable. That is, when you declare something like: int[ubyte[]] x; then the key type of x should be immutable(ubyte)[], not ubyte[]. Otherwise, it just doesn't make any sense, and causes several of the AA-related bugs currently on the bugtracker. In Java and D1, it seems you just have to go on trust if you want your container to accept key types other than strict value types. But can we do better in D2 - short of forcing the key type to be immutable, which would hinder the container's usefulness? But it seems D2 has taken one step in that general direction by automatically tail-consting the key type of an AA. But it doesn't stop modifications to the key through mutable references to the data. Exactly. AA keys must be immutable, no matter what. Of course, to interact nicely with existing code, methods like .opIndex or .get should also accept mutable keys for lookup purposes, and .idup them when a new entry needs to be created. And if the key is of class type, you can still modify the object, since D2 conflates constancy of an object reference with constancy of the object itself. This is in itself silly. Really, D should have tail-const built in for stuff like this. This is a major PITA. Especially if you're trying to be const-correct in your code, then it leads to nonsense like being unable to traverse a linked list inside a const method, because the iteration pointer itself is const (whereas it's the *data* it's pointing to that's const) so you can't overwrite the loop variable. However, you *can* recursively search the list. I find this to be a major WAT in D. [...] I suppose there are a few possibilities for what constancy to apply to elements of a data structure to which changes might affect the structure's integrity: (a) force the type to be tail-const if it's an array, otherwise don't add any constancy (b) force the type to be tail-const if it's an array, or fully const if it's a class (c) force the type to be tail-immutable if it's an array, otherwise don't add any constancy (d) force the type to be tail-immutable if it's an array, or fully immutable if it's a class (e) don't add any constancy, but just rely on trust Currently, AAs implement (a). Which is prone to bugs. (d) guarantees that changes to the data that mess up the data structure will never happen, at least if the programmer doesn't bypass the const system. [...] I believe this is the best way to go. Well, at least for AA's this is needed. Otherwise there will always be the possibility that AA's will malfunction when the key changes behind the container's back. T -- Just because you survived after you did it, doesn't mean it wasn't stupid!
Re: DI Generation Needs your Help!
On 12/19/11, Adam Wilson flybo...@gmail.com wrote: If anyone wishes to test my changes against their code, you can download them from my git account here: https://lightben...@github.com/LightBender/dmd.git This seems to work nicely even with the latest release. It's much better than the current .di generation for sure. Any plans on merging this with mainline before it goes stale?
Re: Implicit string lit conversion to wstring/dstring
On Wed, Mar 14, 2012 at 02:07:04PM -0500, Andrei Alexandrescu wrote:
On 3/14/12 2:01 PM, H. S. Teoh wrote:
However, this change broke this code:
AssociativeArray!(wstring,int) aa;
aa[abc] = 123;// error: compiler deduces K as string,
// so isCompatWithKey!K fails: string
// can't implicitly convert to wstring
Whereas before, when opIndexAssign looked like this:
void opIndexAssign(in Value v, in Key key)
{
...
}
everything worked, because the compiler deduces the type of abc as
wstring since Key==wstring.
Aha! This is one of those cases in which built-in magic smells of
putrid beef soup.
+1.
I think it's possible to still make this work by beefing up the
template constraints such that the working signature is selected for
strings.
[...]
I tried the following, but it still doesn't work properly:
void opIndexAssign()(in Value v, in Key key)
{
__opIndexAssignImpl(v, key);
}
void opIndexAssign(K)(in Value v, in K key)
if (!is(K==Key) isCompatWithKey!K)
{
__opIndexAssignImpl(v, key);
}
This causes this case to fail:
AssociativeArray!(wstring,int) aa;
wchar[] key = abcw.dup;
aa[key] = 123; // Error: template
newAA.AA!(immutable(wchar)[],int).AssociativeArray.opIndexAssign() cannot
deduce template function from argument types !()(int,wchar[])
I don't understand what's happening here. The condition !is(K==Key)
is necessary because otherwise the compiler complains that more than one
template matches the given call, but for some weird reason both
templates vanish from consideration when the condition is put in.
T
--
It is the quality rather than the quantity that matters. -- Lucius Annaeus
Seneca
Re: DI Generation Needs your Help!
On 3/14/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
This seems to work nicely even with the latest release. It's much
better than the current .di generation for sure. Any plans on merging
this with mainline before it goes stale?
Although I would really like to be able to keep documentation comments
in the .di files, e.g.:
class Foo {
/** Commented ctor. */
this() { }
}
-
class Foo {
/** Commented ctor. */
this();
}
Re: Implicit string lit conversion to wstring/dstring
On Wed, Mar 14, 2012 at 02:07:04PM -0500, Andrei Alexandrescu wrote:
On 3/14/12 2:01 PM, H. S. Teoh wrote:
However, this change broke this code:
AssociativeArray!(wstring,int) aa;
aa[abc] = 123;// error: compiler deduces K as string,
// so isCompatWithKey!K fails: string
// can't implicitly convert to wstring
Whereas before, when opIndexAssign looked like this:
void opIndexAssign(in Value v, in Key key)
{
...
}
everything worked, because the compiler deduces the type of abc as
wstring since Key==wstring.
Aha! This is one of those cases in which built-in magic smells of
putrid beef soup.
I think it's possible to still make this work by beefing up the
template constraints such that the working signature is selected for
strings.
[...]
Also, IMHO, this needs to work for array literals in general, not just
strings. For example, this should work:
int[ubyte[]] aa;
aa[[1,2,3]] = 123;
The [1,2,3] should be deduced as ubyte[] instead of int[].
T
--
Ignorance is bliss... but only until you suffer the consequences!
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 18:28, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote: Le 14/03/2012 18:00, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote: Le 14/03/2012 17:08, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no? You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example. This doesn't have anything to do with turning signals into exceptions. No but this does, make sense to catch segfault and act according to it to implement such a functionality. This is a very close problem. You can't resume D exceptions. I'm not talking about Exception anymore. In case of Exception, this isn't a problem, but in case of regular return, this is.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 18:01, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 16:39:29 UTC, deadalnix wrote: Le 14/03/2012 17:34, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote: Sweet. Yeah, I think you need to use naked and reconstruct the stackframe. Not sure how it'd look; I'm not familiar with the x86_64 ABI. I think it might be safe to just reconstruct the stack frame in the signal handler, and set gregs[REG_EIP] to _d_throw directly. It should also use a pre-allocated exception object (like how it's done with OutofMemoryError and InvalidMemoryOperationError), in case there's data corruption in the GC. Especially if the signal is sent because of stack overflow ! Not sure if sarcasm..? In case of a stack overflow, you can't call _d_throwc (or use the throw statement) anyway. You can page protect the last segment of the stack, and unprotect it before throwing.
Re: Implicit string lit conversion to wstring/dstring
On 3/14/12 2:34 PM, H. S. Teoh wrote:
I tried the following, but it still doesn't work properly:
void opIndexAssign()(in Value v, in Key key)
{
__opIndexAssignImpl(v, key);
}
void opIndexAssign(K)(in Value v, in K key)
if (!is(K==Key) isCompatWithKey!K)
{
__opIndexAssignImpl(v, key);
}
Try special casing for the exact types (string, char[] etc), get that
working, and then generalize from there.
Andrei
Re: Multiple return values...
On Wed, 14 Mar 2012 20:02:50 +0100, Ary Manzana a...@esperanto.org.ar
wrote:
Here's what you can do in Ruby:
a = 1
b = 2
# Swap the contents
a, b = b, a
Can you do something like that with templates in D, with a nice syntax?
template to(T...) {
alias T to;
}
auto from(T...)(T t) {
struct Result { T t; alias t this; }
return Result( t );
}
void main( ) {
int a = 3;
int b = 4;
to!(a, b) = from(b, a);
assert( a == 4 );
assert( b == 3 );
}
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wednesday, 14 March 2012 at 19:48:28 UTC, deadalnix wrote: Le 14/03/2012 18:28, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote: Le 14/03/2012 18:00, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote: Le 14/03/2012 17:08, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no? You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example. This doesn't have anything to do with turning signals into exceptions. No but this does, make sense to catch segfault and act according to it to implement such a functionality. This is a very close problem. You can't resume D exceptions. I'm not talking about Exception anymore. In case of Exception, this isn't a problem, but in case of regular return, this is. I don't understand how any of your posts are related to this thread at all. This thread is about turning SIGSEGV into an exception that 1) you can catch 2) will print a stack trace when uncaught. You've brought in stack overflows, moving garbage collectors, etc. I assure you, we are well-aware of the problems when using this exact code for other purposes.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On 13/03/12 11:09, FeepingCreature wrote:
Note: I worked out this method for my own language, Neat, but the basic
approach should be portable to D's exceptions as well.
I've seen it argued a lot over the years (even argued it myself) that it's
impossible to throw from Linux signal handlers. This is basically correct,
because they constitute an interruption in the stack that breaks exceptions'
ability to unroll properly.
However, there is a method to turn a signal handler into a regular function
call that you can throw from.
Basically, what we need to do is similar to a stack buffer overflow exploit.
Under Linux, the extended signal handler that is set with sigaction is called
with three arguments: the signal, a siginfo_t* and a ucontext_t* as the third.
The third parameter is what we're interested in. Deep inside the ucontext_t
struct is uc.mcontext.gregs[REG_EIP], the address of the instruction that
caused the segfault. This is the location that execution returns to when the
signal handler returns. By overwriting this location, we can turn a return into
a function call.
First, gregs[REG_EAX] = gregs[REG_EIP];
We can safely assume that the function that caused the segfault doesn't really
need its EAX anymore, so we can reuse it to reconstruct a proper stackframe to
throw from later.
Second, gregs[REG_EIP] = cast(void*)sigsegv_userspace_handler;
Note that the naked attribute was not used. If used, it can make this code
slightly easier.
extern(C) void sigsegv_userspace_handler() {
// done implicitly
// asm { push ebp; }
// asm { mov ebp, esp; }
asm { mov ebx, [esp]; } // backup the pushed ebp
asm { mov [esp], eax; } // replace it with the correct return address
// which was originally left out due to the
// irregular way we entered this function (via a
ret).
asm { push ebx; } // recreate the pushed ebp
asm { mov ebp, esp; } // complete stackframe.
// originally, our stackframe (because we entered this function via a ret)
// was [ebp]. Now, it's [return address][ebp], as is proper for cdecl.
// at this point, we can safely throw
// (or invoke any other non-handler-safe function).
throw new SignalException(SIGSEGV);
}
I didn't realize that was possible. Very interesting.
As it stands, though, that's got some pretty serious issues.
You are on the stack of the function that was called, but you don't know
for sure that it is a valid stack.
asm {
push EBX;
mov EBX, ESP;
mov ESP, 0;// Look ma, no stack!
mov int ptr [ESP], 0; // segfault -- null pointer exception
mov ESP, EBX;
pop EBX;
}
Now, your user space handler will cause another segfault when it does
the mov [ESP], 0. I think that gives you an infinite loop.
I think the idea would work, if you had some guarantee that the stack
pointer was valid. Then, call a separate handler if it is not.
The primary 'trick' in Windows SEH is that it goes to great lengths to
verify that the stack is valid. I'm not sure that in Linux user space
you have enough information to verify it. But maybe you do. At least,
you should be able to check that it's in memory which is owned by your
process.
Would be awesome if it is possible.
Re: Multiple return values...
On 3/14/12 5:00 PM, Simen Kjærås wrote:
On Wed, 14 Mar 2012 20:02:50 +0100, Ary Manzana a...@esperanto.org.ar
wrote:
Here's what you can do in Ruby:
a = 1
b = 2
# Swap the contents
a, b = b, a
Can you do something like that with templates in D, with a nice syntax?
template to(T...) {
alias T to;
}
auto from(T...)(T t) {
struct Result { T t; alias t this; }
return Result( t );
}
void main( ) {
int a = 3;
int b = 4;
to!(a, b) = from(b, a);
assert( a == 4 );
assert( b == 3 );
}
Awesome! :-)
Re: Implicit string lit conversion to wstring/dstring
On 03/14/2012 08:34 PM, H. S. Teoh wrote:
On Wed, Mar 14, 2012 at 02:07:04PM -0500, Andrei Alexandrescu wrote:
On 3/14/12 2:01 PM, H. S. Teoh wrote:
However, this change broke this code:
AssociativeArray!(wstring,int) aa;
aa[abc] = 123; // error: compiler deduces K as string,
// so isCompatWithKey!K fails: string
// can't implicitly convert to wstring
Whereas before, when opIndexAssign looked like this:
void opIndexAssign(in Value v, in Key key)
{
...
}
everything worked, because the compiler deduces the type of abc as
wstring since Key==wstring.
Aha! This is one of those cases in which built-in magic smells of
putrid beef soup.
+1.
I think it's possible to still make this work by beefing up the
template constraints such that the working signature is selected for
strings.
[...]
I tried the following, but it still doesn't work properly:
void opIndexAssign()(in Value v, in Key key)
{
__opIndexAssignImpl(v, key);
}
void opIndexAssign(K)(in Value v, in K key)
if (!is(K==Key) isCompatWithKey!K)
{
__opIndexAssignImpl(v, key);
}
This causes this case to fail:
AssociativeArray!(wstring,int) aa;
wchar[] key = abcw.dup;
aa[key] = 123; // Error: template
newAA.AA!(immutable(wchar)[],int).AssociativeArray.opIndexAssign() cannot
deduce template function from argument types !()(int,wchar[])
I don't understand what's happening here. The condition !is(K==Key)
is necessary because otherwise the compiler complains that more than one
template matches the given call, but for some weird reason both
templates vanish from consideration when the condition is put in.
T
Use this for now:
void opIndexAssign(K)(in int v, scope K key)
if (!is(K==Key) isCompatWithKey!K)
{...}
'in K key'/const(K) key will only IFTI-match a const type. I don't think
that is sensible at all, you may want to file a bug report.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 21:07, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 19:48:28 UTC, deadalnix wrote: Le 14/03/2012 18:28, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote: Le 14/03/2012 18:00, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote: Le 14/03/2012 17:08, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote: You are loosing EAX in the process. When would this matter? EAX is a scratch register per ABIs, no? You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example. This doesn't have anything to do with turning signals into exceptions. No but this does, make sense to catch segfault and act according to it to implement such a functionality. This is a very close problem. You can't resume D exceptions. I'm not talking about Exception anymore. In case of Exception, this isn't a problem, but in case of regular return, this is. I don't understand how any of your posts are related to this thread at all. This thread is about turning SIGSEGV into an exception that 1) you can catch 2) will print a stack trace when uncaught. You've brought in stack overflows, moving garbage collectors, etc. I assure you, we are well-aware of the problems when using this exact code for other purposes. The topic is *Turning a SIGSEGV into a regular function call under Linux, allowing throw*, not only Exception. I don't understand what is the problem here ? Can't we talk about how we could keep trash register clean in case we don't throw - this doesn't make much sense if we throw anyway - ? What your are mentioning here is already done. Nothing to discuss about that. This is why I try to jump into the next topic : how can we do more than just throwing.
Re: Implicit string lit conversion to wstring/dstring
On 03/14/2012 09:18 PM, Timon Gehr wrote:
Use this for now:
void opIndexAssign(K)(in int v, scope K key)
if (!is(K==Key) isCompatWithKey!K)
{...}
oops.
I meant:
void opIndexAssign(K)(in Value v, scope K key)
if (!is(K==Key) isCompatWithKey!K)
{...}
'in K key'/const(K) key will only IFTI-match a const type. I don't think
that is sensible at all, you may want to file a bug report.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wednesday, 14 March 2012 at 20:20:05 UTC, deadalnix wrote: The topic is *Turning a SIGSEGV into a regular function call under Linux, allowing throw*, not only Exception. I don't understand what is the problem here ? Can't we talk about how we could keep trash register clean in case we don't throw - this doesn't make much sense if we throw anyway - ? What your are mentioning here is already done. Nothing to discuss about that. This is why I try to jump into the next topic : how can we do more than just throwing. OK. But (to me, at least) you sounded like you were criticizing the implementation for solving that specific task, so it would help if you were clearer of your intentions. For example, losing the contents EAX is relativery harmless, but the contents of EBP, EGS etc. can be very important.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston d...@nospam.com wrote: Now, your user space handler will cause another segfault when it does the mov [ESP], 0. I think that gives you an infinite loop. SEGFAULT inside a SEGV signal handler aborts the program (no way to turn this off IIRC). -Steve
Re: Container templates and constancy of elements
On 03/14/2012 12:24 PM, H. S. Teoh wrote:
On Wed, Mar 14, 2012 at 06:51:54PM +, Stewart Gordon wrote:
With some containers, such as lists and trees (binary search trees
aside), it doesn't matter if the elements can change state, since
the data structure remains well-formed.
However, with others, such as sets and AAs, it's desirable if the
keys don't mutate. Any operations on them won't work right if there
are keys in the wrong hash slots or out of order (depending on the
underlying data structure) because they have changed since being put
into the container. Of course, this doesn't apply to _values_ in an
AA, since these can safely mutate.
IMO, AA keys should be *implicitly* immutable. That is, when you declare
something like:
int[ubyte[]] x;
then the key type of x should be immutable(ubyte)[], not ubyte[].
Yes, the internally stored copy of the key should be immutable(ubyte[]).
Please note the difference from yours, but I guess that extra protection
is just to protect the developers from themselves by avoiding mutating
the key in the implementation.
But the conceptual key type of the AA should be const(ubyte[]). The
reason is, a const parameter is welcoming: It says I accept both
mutable and immutable as arguments. On the other hand, an immutable
parameter is restricting: It says I demand only immutable as argument.
The following opIndex accepts keys of five different types of immutability:
class SingleElementAA
{
immutable(uint[]) key;
int value;
ref int opIndex(const(uint[]) key)
{
return value;
}
}
void main()
{
auto aa = new SingleElementAA();
uint[] mutable;
immutable(uint)[] element_immutable;
immutable(uint[]) all_immutable;
enum uint[] enum_immutable = [ 1 ];
aa[mutable] = 42;
aa[element_immutable] = 43;
aa[all_immutable] = 44;
aa[enum_immutable] = 45;
aa[[0, 1]] = 42; // literal key
}
Ali
Re: Container templates and constancy of elements
On Wed, 14 Mar 2012 14:51:54 -0400, Stewart Gordon smjg_1...@yahoo.com wrote: With some containers, such as lists and trees (binary search trees aside), it doesn't matter if the elements can change state, since the data structure remains well-formed. However, with others, such as sets and AAs, it's desirable if the keys don't mutate. Any operations on them won't work right if there are keys in the wrong hash slots or out of order (depending on the underlying data structure) because they have changed since being put into the container. Of course, this doesn't apply to _values_ in an AA, since these can safely mutate. In Java and D1, it seems you just have to go on trust if you want your container to accept key types other than strict value types. But can we do better in D2 - short of forcing the key type to be immutable, which would hinder the container's usefulness? But it seems D2 has taken one step in that general direction by automatically tail-consting the key type of an AA. But it doesn't stop modifications to the key through mutable references to the data. And if the key is of class type, you can still modify the object, since D2 conflates constancy of an object reference with constancy of the object itself. This is in itself silly. Really, D should have tail-const built in for stuff like this. OK, so there's Rebindable, but I've found it to be a PITA when trying to do generic programming with it, as well as leading to this AA key anomaly because it isn't a built-in feature. I suppose there are a few possibilities for what constancy to apply to elements of a data structure to which changes might affect the structure's integrity: (a) force the type to be tail-const if it's an array, otherwise don't add any constancy (b) force the type to be tail-const if it's an array, or fully const if it's a class (c) force the type to be tail-immutable if it's an array, otherwise don't add any constancy (d) force the type to be tail-immutable if it's an array, or fully immutable if it's a class (e) don't add any constancy, but just rely on trust Currently, AAs implement (a). (d) guarantees that changes to the data that mess up the data structure will never happen, at least if the programmer doesn't bypass the const system. (e) is the route D1 and Java are forced to take. Am I right in thinking that sets and maps in the C++ STL take the same path? Anyway, what are people's thoughts on the right way to go here? IMO, @safe code should only allow d, @system/trusted should allow e. And the compiler shouldn't be helping you by adding const annotations. That is: int[char[]] aa; this line should either compile, and the type should be int[char[]] aa, or it should not compile. D is supposed to be able to do at your own risk bare-metal types of things. This seems like it unnecessarily limits code. -Steve
Re: DI Generation Needs your Help!
On Wed, 14 Mar 2012 12:30:00 -0700, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 12/19/11, Adam Wilson flybo...@gmail.com wrote: If anyone wishes to test my changes against their code, you can download them from my git account here: https://lightben...@github.com/LightBender/dmd.git This seems to work nicely even with the latest release. It's much better than the current .di generation for sure. Any plans on merging this with mainline before it goes stale? I am currently maintaining this against DMD HEAD, but until this bug (http://d.puremagic.com/issues/show_bug.cgi?id=7423) gets fixed I can't open a pull request because the patch will break both the Phobos and DRuntime builds badly without it. I would fix the bug myself, but I am getting married in a month and am rather short on time. Earliest I'll likely be able to investigate a fix is May. If anyone else wants to take a shot at a fix before then, I'd happily open up a pull request once they're done.
Re: DI Generation Needs your Help!
On Wed, 14 Mar 2012 12:35:03 -0700, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 3/14/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
This seems to work nicely even with the latest release. It's much
better than the current .di generation for sure. Any plans on merging
this with mainline before it goes stale?
Although I would really like to be able to keep documentation comments
in the .di files, e.g.:
class Foo {
/** Commented ctor. */
this() { }
}
-
class Foo {
/** Commented ctor. */
this();
}
I'll look into it when I get the chance. :-)
--
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Re: DI Generation Needs your Help!
El 19/12/2011 9:11, Adam Wilson escribió: 1. Function Implementations are removed What about function inlining? would it work from a different module? I think the implementation of small functions should be kept so that client code can inline them. The current DMD does this apparently, it keeps small functions in .di files.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On 14/03/12 21:31, Steven Schveighoffer wrote: On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston d...@nospam.com wrote: Now, your user space handler will cause another segfault when it does the mov [ESP], 0. I think that gives you an infinite loop. SEGFAULT inside a SEGV signal handler aborts the program (no way to turn this off IIRC). -Steve But you're not inside the signal handler when it happens. You returned.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On 03/14/12 21:08, Don Clugston wrote:
I didn't realize that was possible. Very interesting.
As it stands, though, that's got some pretty serious issues.
You are on the stack of the function that was called, but you don't know for
sure that it is a valid stack.
asm {
push EBX;
mov EBX, ESP;
mov ESP, 0;// Look ma, no stack!
mov int ptr [ESP], 0; // segfault -- null pointer exception
mov ESP, EBX;
pop EBX;
}
Now, your user space handler will cause another segfault when it does the mov
[ESP], 0. I think that gives you an infinite loop.
I think that case is sufficiently rare that it'd have to count somewhere
between act of god and outright developer malice. The assumption that the
stack frame is valid is, I'd say, safe to make in the vast majority of cases.
You pretty much have to actively try to break it, for no clearly discernible
reason.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Wed, 14 Mar 2012 16:45:49 -0400, Don Clugston d...@nospam.com wrote: On 14/03/12 21:31, Steven Schveighoffer wrote: On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston d...@nospam.com wrote: Now, your user space handler will cause another segfault when it does the mov [ESP], 0. I think that gives you an infinite loop. SEGFAULT inside a SEGV signal handler aborts the program (no way to turn this off IIRC). -Steve But you're not inside the signal handler when it happens. You returned. Then how does the signal handler do anything? I mean, doesn't it need a stack? Or does it just affect register variables? Most signal handlers are normal functions, and isn't there some usage of the stack to save registers? It seems there should be a way to turn off the signal handler during the time when you are suspicous of the stack being the culprit, then re-engage the signal handler before throwing the error. -Steve
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
On Mar 14, 2012, at 1:54 PM, FeepingCreature wrote: I think that case is sufficiently rare that it'd have to count somewhere between act of god and outright developer malice. The assumption that the stack frame is valid is, I'd say, safe to make in the vast majority of cases. You pretty much have to actively try to break it, for no clearly discernible reason. The prevalence of buffer overflow attacks might suggest otherwise.
Re: Container templates and constancy of elements
On 14/03/2012 19:24, H. S. Teoh wrote: snip Exactly. AA keys must be immutable, no matter what. Of course, to interact nicely with existing code, methods like .opIndex or .get should also accept mutable keys for lookup purposes, and .idup them when a new entry needs to be created. This would rely on class authors making sure they define .idup. We would also need a deep version of .idup for array-of-array and array-of-class types. snip (d) guarantees that changes to the data that mess up the data structure will never happen, at least if the programmer doesn't bypass the const system. [...] I believe this is the best way to go. Well, at least for AA's this is needed. Otherwise there will always be the possibility that AA's will malfunction when the key changes behind the container's back. Thinking about it, if we're going to go this far, maybe we could just make the key type fully immutable whatever it is. This would enable the key variable in a foreach to be ref for efficiency (especially useful if it's a struct type) and still prevent changing of the key through it. But this precludes implementing hash slots as arrays, at least if you want to be able to delete elements. I might have to rethink my strategy here as well. A linked list would get around it but increase the memory allocation overhead - not sure if this is worth worrying about. Stewart.
Re: DI Generation Needs your Help!
On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro alvarodotseg...@gmail.com wrote: El 19/12/2011 9:11, Adam Wilson escribió: 1. Function Implementations are removed What about function inlining? would it work from a different module? I think the implementation of small functions should be kept so that client code can inline them. The current DMD does this apparently, it keeps small functions in .di files. The problem is that in DI generation, at least as near as I can tell, D has now idea how big a function is during DI generation. In my experience it was keeping all functions not just small ones. And frankly DI generation is targeted at library builders who are well aware of the inlining trade-offs. And then comes the question of how do you define small functions to an adequately technical level. Because theoretically you can inline ANYTHING. Yes, there are rules the prevent inlining, but you'll also note that the state of these rules is not guaranteed to be known at generation time. DI generation currently works as such. After the code has been parsed into an AST, the compiler runs a special set of virtual functions called toCBuffer (and it's variants) that is used to print out the AST in source form again. NO semantic analysis of any kind has been performed on the AST yet. And you wouldn't want to generate DI's after semantic analysis as the analysis fundamentally alters the AST such that you would not get the same code back out and some things would be missing from the DI files that you intended to be there. The AST at DI generation is an incredibly naive representation of the SOURCE not the SEMANTICS; which is what you would need to determine the eligibility of inlining. The answer that Walter has always given for objections about how DI files are built is that if you want anything customized about the output, you have to do it yourself. DI generation will probably NEVER be as perfect as everyone wants. But I think this solution represents a best effort to get DI files to a point where the community agrees that they would be most useful in achieving their intended purpose, which is as interface files for compiled libraries. It's not perfect, but it gets you A LOT further than the current one, if you need customization beyond that, well, D lets you do that too. :-) -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Multiple return values...
On 14 March 2012 22:10, Ary Manzana a...@esperanto.org.ar wrote:
On 3/14/12 5:00 PM, Simen Kjærås wrote:
On Wed, 14 Mar 2012 20:02:50 +0100, Ary Manzana a...@esperanto.org.ar
wrote:
Here's what you can do in Ruby:
a = 1
b = 2
# Swap the contents
a, b = b, a
Can you do something like that with templates in D, with a nice syntax?
template to(T...) {
alias T to;
}
auto from(T...)(T t) {
struct Result { T t; alias t this; }
return Result( t );
}
void main( ) {
int a = 3;
int b = 4;
to!(a, b) = from(b, a);
assert( a == 4 );
assert( b == 3 );
}
Awesome! :-)
Mmmm, I still kinda like the ruby way.
I agree, the coma operator is a serious liability in D. Multi assignments
without any other rubbish around it are useful in a whole bunch of of
contexts.
How much would really break if coma was deprecated? Is it used any more
than C++ coma? (Most C++ programs wouldn't even know if the coma operator
were removed)
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On 14 March 2012 15:17, Robert Jacques sandf...@jhu.edu wrote: But there's a reason we use /// instead of ⫻; we shouldn't require custom keyboard mappings in order to program efficiently in D. Hold that thought, I think you're missing a major franchising opportunity right there... D branded 'pro-codah' keyboards! Nice! :P
Re: DI Generation Needs your Help!
Adam Wilson: I think I said this before, but for what it's worth, I think your new approach is spot-on correct.
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 21:28, Vladimir Panteleev a écrit : On Wednesday, 14 March 2012 at 20:20:05 UTC, deadalnix wrote: The topic is *Turning a SIGSEGV into a regular function call under Linux, allowing throw*, not only Exception. I don't understand what is the problem here ? Can't we talk about how we could keep trash register clean in case we don't throw - this doesn't make much sense if we throw anyway - ? What your are mentioning here is already done. Nothing to discuss about that. This is why I try to jump into the next topic : how can we do more than just throwing. OK. But (to me, at least) you sounded like you were criticizing the implementation for solving that specific task, so it would help if you were clearer of your intentions. For example, losing the contents EAX is relativery harmless, but the contents of EBP, EGS etc. can be very important. I'm not criticizing at all ! I think this is awesome ! I'm just trying to discuss way we can get to the next step. Loosing EAX is harmless in the throwing case, but it is a problem for other tasks. I didn't mentioned this into the topic, but I'm very enthusiastic about that !
Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw
Le 14/03/2012 21:53, Steven Schveighoffer a écrit : On Wed, 14 Mar 2012 16:45:49 -0400, Don Clugston d...@nospam.com wrote: On 14/03/12 21:31, Steven Schveighoffer wrote: On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston d...@nospam.com wrote: Now, your user space handler will cause another segfault when it does the mov [ESP], 0. I think that gives you an infinite loop. SEGFAULT inside a SEGV signal handler aborts the program (no way to turn this off IIRC). -Steve But you're not inside the signal handler when it happens. You returned. Then how does the signal handler do anything? I mean, doesn't it need a stack? Or does it just affect register variables? Most signal handlers are normal functions, and isn't there some usage of the stack to save registers? It seems there should be a way to turn off the signal handler during the time when you are suspicous of the stack being the culprit, then re-engage the signal handler before throwing the error. -Steve The address of the instruction being executed is hijacked, so, instead of resuming normal operation after the signal handler exit, it get into the throwing handler. This is a very nice trick !
