Re: Reducing Pegged ASTs
On Tue, Nov 25, 2014 at 4:12 PM, "Nordlöw" wrote: > Is there a way to (on the fly) reduce Pegged parse results such as > > C [0, 6]["int", "x", ";"] > +-C.TranslationUnit [0, 6]["int", "x", ";"] > +-C.ExternalDeclaration [0, 6]["int", "x", ";"] >+-C.Declaration [0, 6]["int", "x", ";"] > +-C.DeclarationSpecifiers [0, 4]["int"] > | +-C.TypeSpecifier [0, 4]["int"] > +-C.InitDeclaratorList [4, 5]["x"] > +-C.InitDeclarator [4, 5]["x"] > +-C.Declarator [4, 5]["x"] >+-C.DirectDeclarator [4, 5]["x"] > +-C.Identifier [4, 5]["x"] > > to > > C [0, 6]["int", "x", ";"] > +-C.TranslationUnit [0, 6]["int", "x", ";"] > +-C.ExternalDeclaration [0, 6]["int", "x", ";"] >+-C.Declaration [0, 6]["int", "x", ";"] > +-C.TypeSpecifier [0, 4]["int"] > +-C.Identifier [4, 5]["x"] > > and still, when needed, be able query that C.Identifier is an instance of > C.DirectDeclarator etc? The reducing can be done, either with operators or semantic actions. IIRC there is a free function in Pegged that does it. I did not automate it, because every time I cut down severely a parse tree, I later regret it because I lost information that way. Cutting while still retaining original info (who is this node's ancestor) is more difficult: you would have to store it somewhere anyhow. You cannot create node classes to represent the hierarchy, because of loops in the grammar: an Identifier can have many different ancestors. Note also that Pegged produces parse trees (complete parsing information), not ASTs. ASTs would indeed be much smaller, but we would have to define what are the master nodes in the D grammar. > If not this seems like a cool feature to have ;) > > I guess it would reduce memory requirements by about a magnitude right? If you want to remember the intermediate nodes you cut down, not really, since you still need to store them somehow. I think what's consuming memory right now is that I duplicate the matched strings at each level, even concatenating them at the higher levels. I should let them only in the 'leaves' of the tree (heck, like an AST). Halas, I've no free time to code anything in D these days... but of course, feel free to push any pull request you might have!
Re: Uninitialized object hangs without warning.
On Wednesday, 26 November 2014 at 05:24:49 UTC, Bear Cherian
wrote:
I ran into this a while ago and have already moved on, but I
had a class such as this
Class MyClass{
this(){}
void someFunction(){
//body
}
}
And in my app I had something like
MyClass classObject;
classObject.someFunction();
When I compile, no warnings or errors. But when I run the
application it just hangs at the function call. Eventually the
app kills itself.
The problem is classObject is never initialized. This drove me
crazy for an entire evening before I added a bunch of debug
lines to narrow it down and then visually saw what the problem
was.
I feel there should be some type of warning or error when
compiling, or an error when we get to
classObject.someFunction().
This is on 2.065, so forgive me if this has already been
addressed. Again, it's been a while since I actually
encountered the error, so not sure if i missed an aspect of it.
This *does* cause an error on 2.065:
http://dpaste.dzfl.pl/0d6663890081
Or did you mistakenly type "Class" instead of "class"? In the
above code, when you replace "Class" with "class", it runs and
then segfaults. Either way, there is no hang.
Where did you install the compiler from? This is definitely a
problem on your end.
Uninitialized object hangs without warning.
I ran into this a while ago and have already moved on, but I had
a class such as this
Class MyClass{
this(){}
void someFunction(){
//body
}
}
And in my app I had something like
MyClass classObject;
classObject.someFunction();
When I compile, no warnings or errors. But when I run the
application it just hangs at the function call. Eventually the
app kills itself.
The problem is classObject is never initialized. This drove me
crazy for an entire evening before I added a bunch of debug lines
to narrow it down and then visually saw what the problem was.
I feel there should be some type of warning or error when
compiling, or an error when we get to classObject.someFunction().
This is on 2.065, so forgive me if this has already been
addressed. Again, it's been a while since I actually encountered
the error, so not sure if i missed an aspect of it.
Re: windows linker error
On Wednesday, 26 November 2014 at 01:35:20 UTC, Joakim wrote:
On Tuesday, 25 November 2014 at 23:08:07 UTC, Vlad Levenfeld
wrote:
On Tuesday, 25 November 2014 at 21:22:24 UTC, Vlad Levenfeld
wrote:
On Windows 7 I have built dmd (using the vcxproj), druntime
(win64.mak) and phobos (win64.mak).
I went into sc.ini and set the LINKCMD to point to Visual
Studio 12.0's linker.
When I try to compile anything with dmd, I get
LINK : fatal error LNK1181: cannot open input file
'test,,nul,user32+kernel132/noi;.obj'
I'm pretty sure else is ok as I didn't see any errors while I
was building. What can I try next?
Solved it by pointing to the dmc linker instead. Now I have
LNK1104: cannot open file 'shell32.lib'
I'm compiling with -m64... couldn't compile 32-bit phobos
because of missing zlib.
Just so we're clear, you're trying to compile for Win64 COFF?
It sounds like you don't have something about your environment
set up right, as Win64 requires the MSVC toolchain and some
configuration if you use the dmd zip. Did you install from the
exe installer or are you using the zip?
The dmc linker is not going to work, as it only does OMF. You
may find this page helpful, though it may be a bit outdated:
http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
I'm compiling the latest build from github.
(I normally stay up to date with the current builds on 64bit
Debian and everything works more or less without a hitch there,
but now I need to get some of my tools working in a Windows
environment)
I'm not really sure what my options are regarding the COFF or
what they mean, 64-bit is really the only requirement (mostly
because I can't get the 32-bit stuff to compile).
I've got Visual Studio Premium, I tried to install from the exe
at one point and got Visual D in the process (and this did work,
except that the code I need is built against the latest
dmd/druntime/phobos builds).
Installing it from the instructions, IIRC, also worked for me,
but again, the version.
So I used the dmd visual studio project to build dmd, then built
druntime and phobos with Digital Mars make;
I had previously tried to use dmc to build dmd but couldn't get
it to work.
Anyway, I manage to build successfully but then I get this linker
error when I try to run dmd on some test.d consisting of void
main (){}.
I've gone into sc.ini and pulled out the ;VC2012 comments to
expose the LIB instruction (to fix a different problem) and this
is the point that I've gotten stuck at.
Cheap Kitchen Sale
Cheap Kitchen Sale. Thirty Ex Display Kitchens To Clear. www.exdisplaykitchens1.co.uk £ 595 Each with appliances.Tel 01616-694785
Re: DerelictOrg and SDL_Mixer
On Wednesday, 26 November 2014 at 01:25:51 UTC, Mike Parker wrote: Don't think of it that way. Think of it this way: you have to load every library you want to use. SDL2_mixer is a library, SDL2_image is a library, SDL2_ttf is a library, and so on. You have to load them individually. DerelictSDL2 binds to SDL2, DerelictSDL2Mixer binds to SDL2_mixer and so on. OK! Somehow I had overlooked the most obvious documentation on DerelictSDL2: the readme.md file on the github repository page which displays these informations.. Sorry! The Derelict packages are all just bindings to C libraries and nothing more. To use those libraries, you need to install their dependencies on each platform you need to use them on. If you don't know what the dependencies are, you should visit the website or support forums for that library. Yes, it was an issue unrelated to D or DerelictOrg but still some problem encountered by clueless me on its quest to use SDL_Mixer functions with D.. This might be of some help for a beginner like me who had difficulties to find some straightforward documentation to set everything up. The SDL and SDL_mixer websites did not help much (..or I overlooked some stuffs again).
Re: windows linker error
On Tuesday, 25 November 2014 at 23:08:07 UTC, Vlad Levenfeld wrote: On Tuesday, 25 November 2014 at 21:22:24 UTC, Vlad Levenfeld wrote: On Windows 7 I have built dmd (using the vcxproj), druntime (win64.mak) and phobos (win64.mak). I went into sc.ini and set the LINKCMD to point to Visual Studio 12.0's linker. When I try to compile anything with dmd, I get LINK : fatal error LNK1181: cannot open input file 'test,,nul,user32+kernel132/noi;.obj' I'm pretty sure else is ok as I didn't see any errors while I was building. What can I try next? Solved it by pointing to the dmc linker instead. Now I have LNK1104: cannot open file 'shell32.lib' I'm compiling with -m64... couldn't compile 32-bit phobos because of missing zlib. Just so we're clear, you're trying to compile for Win64 COFF? It sounds like you don't have something about your environment set up right, as Win64 requires the MSVC toolchain and some configuration if you use the dmd zip. Did you install from the exe installer or are you using the zip? The dmc linker is not going to work, as it only does OMF. You may find this page helpful, though it may be a bit outdated: http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
Re: Dub / Derelict confusion
On 11/26/2014 3:27 AM, Paul wrote: I've finally got this working - the SDL FAQ page sort of identifies the cause; the xorg dev files have to be installed before building SDL otherwise you end up with a 'non-x' version (not sure what you'd do with that!). I built SDL first and then tried installing the missing x development files. Yes, the development files aren't going to help you if you've already built the project! They need to be available for the compile & link process.
Re: DerelictOrg and SDL_Mixer
On 11/26/2014 4:42 AM, torea wrote: ok, so basically, each time I want to access some specific functions imported like: import derelict.sdl2.foo; I have to load it like this? DerelictSDL2foo.load(); Don't think of it that way. Think of it this way: you have to load every library you want to use. SDL2_mixer is a library, SDL2_image is a library, SDL2_ttf is a library, and so on. You have to load them individually. DerelictSDL2 binds to SDL2, DerelictSDL2Mixer binds to SDL2_mixer and so on. After that I also got a SDL_mixer error : No such device. This was solved by installing libasound-dev and libpulse-dev and recompiling SDL2. Now I have sound!! The Derelict packages are all just bindings to C libraries and nothing more. To use those libraries, you need to install their dependencies on each platform you need to use them on. If you don't know what the dependencies are, you should visit the website or support forums for that library.
Re: Reducing Pegged ASTs
On 2014-11-25 10:12, "Nordlöw" wrote: Is there a way to (on the fly) reduce Pegged parse results such as I've made an asn.1 parser using pegged tree map, it's not so complex and does the reducing as well. https://github.com/globecsys/asn1.d Most of the meat is in asn1/generator/ In short, it's much easier when you put all the info in the same object, in this case it's an AEntity: https://github.com/globecsys/asn1.d/blob/master/asn1/generator/asntree.d#L239 When the whole tree is done that way, you can easily traverse it and move nodes like a linked list.. I've made a helper function here: https://github.com/globecsys/asn1.d/blob/master/asn1/generator/asntree.d#L10 You can see it being used here: https://github.com/globecsys/asn1.d/blob/38bd1907498cf69a08604a96394892416f7aa3bd/asn1/generator/asntree.d#L109 and then here: https://github.com/globecsys/asn1.d/blob/master/asn1/generator/generator.d#L500 Also, the garbage collector really makes it easy to optimize memory usage, ie. when you use a node in multiple places and need to re-order the tree elements. I still have a bunch of work to do, and I intend on replacing botan's ASN1 functionalities with this and a DER serialization module. Beware, the pegged structure isn't insanely fast to parse because of the recursion limits I implemented very inefficiently because I was too lazy to translate the standard asn.1 BNF into PEG.. Also, the bigger bottleneck would be error strings. For a 1-2 months of work (incl. learning ASN.1), I'm very satisfied with the technology involved and would recommend intermediate structures with traversal helpers.
Re: windows linker error
On Tuesday, 25 November 2014 at 21:22:24 UTC, Vlad Levenfeld wrote: On Windows 7 I have built dmd (using the vcxproj), druntime (win64.mak) and phobos (win64.mak). I went into sc.ini and set the LINKCMD to point to Visual Studio 12.0's linker. When I try to compile anything with dmd, I get LINK : fatal error LNK1181: cannot open input file 'test,,nul,user32+kernel132/noi;.obj' I'm pretty sure else is ok as I didn't see any errors while I was building. What can I try next? Solved it by pointing to the dmc linker instead. Now I have LNK1104: cannot open file 'shell32.lib' I'm compiling with -m64... couldn't compile 32-bit phobos because of missing zlib.
windows linker error
On Windows 7 I have built dmd (using the vcxproj), druntime (win64.mak) and phobos (win64.mak). I went into sc.ini and set the LINKCMD to point to Visual Studio 12.0's linker. When I try to compile anything with dmd, I get LINK : fatal error LNK1181: cannot open input file 'test,,nul,user32+kernel132/noi;.obj' I'm pretty sure else is ok as I didn't see any errors while I was building. What can I try next?
Re: DerelictOrg and SDL_Mixer
On Tuesday, 25 November 2014 at 09:27:08 UTC, Mike Parker wrote: Every time you call DerelictFoo.load, you are loading exactly one library. You will never see a Derelict package that loads multiple libraries in one call. ok, so basically, each time I want to access some specific functions imported like: import derelict.sdl2.foo; I have to load it like this? DerelictSDL2foo.load(); Is there some documentation about the usage of DerelictOrg with this kind of information? I couldn't find anything useful. The solution to my original problem was the missing line DerelictSDL2Mixer.load(); So thanks again, Jack! After that I also got a SDL_mixer error : No such device. This was solved by installing libasound-dev and libpulse-dev and recompiling SDL2. Now I have sound!!
Re: A nice D coding pattern
On 11/25/2014 10:58 AM, Tobias Pankrath wrote:
>> void main() {
>> // Created at compile-time.
>> enum something = "".Foo;
>>
>
> I don't think we should encourage UFCS with typenames or uppercase
> names. If anything, it does not provide any benefit in this case and
> Foo(".") is much more clearer without any syntactical overhead.
Agreed.
A guideline that makes sense to me is "UFCS is for when the function can
be thought of as a special operation on its first parameter."
After seeing bearophile's code, I thought that even the following was
better than UFCS:
"hello".to!Foo
It only then feels like a special operation on "hello". (I haven't tried
the code but I think it works.)
However, I would still use the Foo("hello").
Ali
Re: A nice D coding pattern
On 11/25/2014 01:51 AM, matovitch wrote: > On Monday, 24 November 2014 at 22:50:33 UTC, bearophile wrote: > Sometimes your forum post doesn't get > any answers but you can be sure I read and enjoy them all (and I'm sure > I am not alone). Keep it up ! :) Same here! Thank you, bearophile! :) An artist friend of mine is working on the book cover for "Programming in D". Initially, I thought of having a subtle reference to a bear. :) (We are not pursuing that idea though.) Ali
Re: A nice D coding pattern
void main() {
// Created at compile-time.
enum something = "".Foo;
I don't think we should encourage UFCS with typenames or
uppercase names. If anything, it does not provide any benefit in
this case and Foo(".") is much more clearer without any
syntactical overhead.
Re: Dub / Derelict confusion
On Sunday, 23 November 2014 at 00:37:07 UTC, Mike Parker wrote: On 11/23/2014 3:52 AM, Paul wrote: Whenever I try to learn a new language I always seem to end up fighting the OS or the IDE rather than spending time where I should. Therefore, I'm going to put this idea on hold and stick to console programs for a while (tried to install ncurses as well earlier but dub doesn't like the "~master" setting in dub.json - grrr!). DUB used to support using github branches for the version, but it was deprecated not so long ago. There's a workaround for it, though, IIRC. If you search the dub forums [1], or ask about it there, you should get an answer. [1] http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/ I've finally got this working - the SDL FAQ page sort of identifies the cause; the xorg dev files have to be installed before building SDL otherwise you end up with a 'non-x' version (not sure what you'd do with that!). I built SDL first and then tried installing the missing x development files.
Re: A nice D coding pattern
On Tuesday, 25 November 2014 at 13:56:23 UTC, bearophile wrote: Right. So the instance data of the struct is more likely correct when you call its methods. Thanks. - Well I'd like to see more of these tips. My current code in D looks like C++ and of course I sure that I'm not extracting the power of D. In fact lately I was looking around the Phobos source to open my mind for new features. Matheus.
Re: A nice D coding pattern
That's a neat trick, although if preconditions were able to be run at compile time when possible you wouldn't have to resort to using enum to force CTFE (you've talked a bit about this before I remember). Thinking about something like a good ranged number implementation, we can now get almost all the way there. Manually having to specify enum is still an undesirable.
Re: Reducing Pegged ASTs
On Tuesday, 25 November 2014 at 15:12:39 UTC, Nordlöw wrote: I guess it would reduce memory requirements by about a magnitude right? Correction: For consistency we probably want this example to be reduced to +-C.Declaration [0, 6]["int", "x", ";"] +-C.TypeSpecifier [0, 4]["int"] +-C.Identifier [4, 5]["x"]
Re: Reducing Pegged ASTs
On Tuesday, 25 November 2014 at 15:15:40 UTC, Nordlöw wrote: +-C.Declaration [0, 6]["int", "x", ";"] +-C.TypeSpecifier [0, 4]["int"] +-C.Identifier [4, 5]["x"] Correction again: +-C.Declaration [0, 6]["int", "x", ";"] +-C.TypeSpecifier [0, 4]["int"] +-C.Identifier [4, 5]["x"]
Reducing Pegged ASTs
Is there a way to (on the fly) reduce Pegged parse results such as C [0, 6]["int", "x", ";"] +-C.TranslationUnit [0, 6]["int", "x", ";"] +-C.ExternalDeclaration [0, 6]["int", "x", ";"] +-C.Declaration [0, 6]["int", "x", ";"] +-C.DeclarationSpecifiers [0, 4]["int"] | +-C.TypeSpecifier [0, 4]["int"] +-C.InitDeclaratorList [4, 5]["x"] +-C.InitDeclarator [4, 5]["x"] +-C.Declarator [4, 5]["x"] +-C.DirectDeclarator [4, 5]["x"] +-C.Identifier [4, 5]["x"] to C [0, 6]["int", "x", ";"] +-C.TranslationUnit [0, 6]["int", "x", ";"] +-C.ExternalDeclaration [0, 6]["int", "x", ";"] +-C.Declaration [0, 6]["int", "x", ";"] +-C.TypeSpecifier [0, 4]["int"] +-C.Identifier [4, 5]["x"] and still, when needed, be able query that C.Identifier is an instance of C.DirectDeclarator etc? If not this seems like a cool feature to have ;) I guess it would reduce memory requirements by about a magnitude right?
Re: A nice D coding pattern
MattCoder: May I understand that you're "disabling" the "default" constructor of the struct to use your own constructor? Right. So the instance data of the struct is more likely correct when you call its methods. Bye, bearophile
Re: A nice D coding pattern
On Monday, 24 November 2014 at 22:50:33 UTC, bearophile wrote: And the @disable this() assures that a struct is correctly initialized by the constructor. In the statement: @disable this() May I understand that you're "disabling" the "default" constructor of the struct to use your own constructor? Matheus.
Re: A nice D coding pattern
On Monday, 24 November 2014 at 22:50:33 UTC, bearophile wrote: In some D programs I'm using this coding pattern: You can see an example of this pattern that I've used here: http://rosettacode.org/wiki/Solve_a_Hopido_puzzle#D Bye, bearophile Awesome gist and great pattern ! Sometimes your forum post doesn't get any answers but you can be sure I read and enjoy them all (and I'm sure I am not alone). Keep it up ! :)
Re: DerelictOrg and SDL_Mixer
On 11/25/2014 9:26 AM, torea wrote: Oh.. I didn't know about the DerelictSDL2Mixer.load()! I thought the initialization of sdl_mixer was done with DerelictSDL2.load() Every time you call DerelictFoo.load, you are loading exactly one library. You will never see a Derelict package that loads multiple libraries in one call.
