Re: So, You Want To Write Your Own Programming Language?
On Thursday, 23 January 2014 at 10:24:23 UTC, Chris wrote: A good example are headlines. A classic is Driver refused license. Now, everybody will assume that it was not the driver who refused the license (default assumption or the _unmarked case_). Why it's not a driver who refused a license?
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 13:37:07 UTC, Sönke Ludwig wrote:
I'm getting deprecation warnings inside std.datetime to use
any instead of canFind.
Also DMD now warns about using FP operators, such as =, for
detecting NaN's. What's the rationale for this? One issue with
this is that isNaN cannot be used for CTFE.
To detect NaNs, you just need to change x = x into x == x.
Actually almost all uses of isNaN in std.math are unnecessarily
slow, std.math.isNaN doesn't trigger signalling NaNs but almost
every function in std.math _should_ trigger signalling NaNs, so
should use the much faster
bool isNaN(real x) { return x != x; }
Re: dmd 2.065 beta 1 #2
Am 27.01.2014 10:37, schrieb Don: On Wednesday, 22 January 2014 at 13:37:07 UTC, Sönke Ludwig wrote: I'm getting deprecation warnings inside std.datetime to use any instead of canFind. Also DMD now warns about using FP operators, such as =, for detecting NaN's. What's the rationale for this? One issue with this is that isNaN cannot be used for CTFE. To detect NaNs, you just need to change x = x into x == x. I've used x = 0 so far to avoid having the x expression appear twice, not really a problem to change it, but I was a bit surprised about the warning. So if I understand it correctly (someone mentioned it somewhere on the .D group), all FP specific comparison operators are going to get deprecated?
Re: dmd 2.065 beta 1 #2
Am 22.01.2014 14:37, schrieb Sönke Ludwig: There is also a build issue that sometimes occurred at the same place in 2.064 in the form of template instantiation failures and now produces linker errors: https://github.com/rejectedsoftware/vibe.d/issues/458 https://d.puremagic.com/issues/show_bug.cgi?id=12010 Another error with undefined symbols is still being reduced by Dustmite and will likely take another two days (unfortunately it involves a fairly large code base with multiple separate static libraries).
Re: DUB 0.9.21 beta 3
Am 27.01.2014 04:33, schrieb Jakob Ovrum: On Wednesday, 15 January 2014 at 14:12:47 UTC, Sönke Ludwig wrote: A new and hopefully last beta version of DUB 0.9.21 has been released: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/826/ It contains some major new features, so extensive testing is needed to get a solid release. When using dub-test on one of my projects, I'm getting: dub_test_root.d(15): Error: module deimos.ev from file libev\deimos\ev.d must be imported as module 'deimos.ev' dub_test_root appears to import it as `libev.deimos.ev`, which is wrong. It looks like it should instead be looking at the module statement for how to import. The dub.json and project hierarchy can be found here[1]. [1] https://github.com/JakobOvrum/Dirk I think there are two possibilities to solve this: - Like you already suggested, use the module statement of each file. This, however, will require to read and parse every source file - something which isn't required so far and I'd like to avoid that, if possible. Also, using the module statement will also not work in general, if not all files are compiled on the same compiler command line. - Use the closest matching import folder to infer the module name instead of the first match (i.e. ./libev instead of . in this case). However, apart from this, this (quite popular) kind of file structure really is a pet peeve of mine. Anyone who uses the library can now do things like import irc.client; // good import deimos.ev; // bad - conflicts with any library that uses the // libev DUB package import libev.deimos.ev; // bad - conflicts with the module statement import loader.windows; // bad - likely conflicts with other libraries I understand that it is popular because a separate source or src folder can be avoided*. But it really is quite unclean considering how importing modules works in D. * and it makes it harder for people to find the actual source code
Re: DUB 0.9.21 beta 3
Am 27.01.2014 13:14, schrieb Sönke Ludwig: - Use the closest matching import folder to infer the module name instead of the first match (i.e. ./libev instead of . in this case). Implemented: https://github.com/rejectedsoftware/dub/commit/5d0867fef7c6415e300c6ce214aa5790d0a2ca93
Re: DUB 0.9.21 beta 3
On Monday, 27 January 2014 at 12:38:06 UTC, Sönke Ludwig wrote: Am 27.01.2014 13:14, schrieb Sönke Ludwig: - Use the closest matching import folder to infer the module name instead of the first match (i.e. ./libev instead of . in this case). Implemented: https://github.com/rejectedsoftware/dub/commit/5d0867fef7c6415e300c6ce214aa5790d0a2ca93 Would it be reasonable to add dub edit to automatically edit the package/dub.json file?
New debugger for D!!!
I'm planning to release a new debugger for D sometime during end
of February. This is a heads up for all those who are eagerly
looking for a good debugger for D.
Here is a sample debug session:
$ ./dbg ./dbg
New session s1 (./dbg) started
New process p1 (program dbg) created
p1.1 SUSPENDED [D main in dbg.d]
78: main(string[] args)
dbg list 175
Source listing for thread p1.1, program dbg
175: if (srcpath !is null)
176: dv_dbgSrcpath(srcpath);
177: if (sympath !is null)
178: dv_dbgSympath(sympath);
179: auto cmd = new Command(uiType);
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
181: if (dbgrc is null)
182: {
183: dbgrc = homedir ~ / ~ DBGRC_FILE;
184: cmd.rc_exec(dbgrc);// home dir dbgrc
dbg run -u 179
p1.1 SUSPENDED [D main in dbg.d]
179: auto cmd = new Command(uiType);
dbg step -o
p1.1 STEPPED [D main in dbg.d]
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
dbg help
Run help on the following topics to get additional help.
Start Stop:
create, grab, quit, release, %follow, %srcpath, %sympath
Execution:
halt, jump, kill, run, step, wait, %thread
Events:
events, onstop, signal, stop, syscall, %lastevent, %thisevent
View or Modify:
dump, list, maps, print, regs, set, stack, status, symbols,
vars, which
%dbg_lang, %file, %frame, %func, %lang, %line, %list_file,
%list_line,
%loc, %num_lines
Convenience:
!, alias, help, logoff, logon, script, %cwd, %logfile,
%log_prefix,
%prompt, %result, %verbose
For a full list of help topics, run help toc.
dbg help create
SYNOPSIS:
create [-f follow] [-l] [-s srcpath] [-S sympath]
[shell_cmd_string]
DESCRIPTION:
Create a new debugging session for shell_cmd_string. The
existing debug
sessions are not affected by this command. One could
simultaneously
have multiple debug sessions. If shell_cmd_string is not
specified, the
shell_cmd_string from previous create command is used and
the previous
create session is destroyed. After the session is created,
this command
runs all the processes till their 'start' function.
OPTIONS:
-ffollow 'prog', 'proc', 'thread' or 'all' or 'none'
-lload only; do not run new program / thread till its
'start' function
-spaths for source files
-Spaths for debug symbol files
NOTES:
It is not possible to redirect or pipe the output of create
command.
EXAMPLES:
create test_prog1 arg1 arg2 2/tmp/prog1.err | test_prog2
# creates a new debug session for test_prog1 and
test_prog2
create MANPAGER=more man 1p man
create xterm -e ./cmd
SEE ALSO:
events, quit, kill, release, run, shell_cmd_string, status,
step
%dbg_follow, %dbg_srcpath, %dbg_sympath, %follow, %srcpath,
%sympath
dbg
Re: New debugger for D!!!
On Monday, 27 January 2014 at 17:10:06 UTC, John Colvin wrote:
On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote:
I'm planning to release a new debugger for D sometime during
end of February. This is a heads up for all those who are
eagerly looking for a good debugger for D.
Here is a sample debug session:
$ ./dbg ./dbg
New session s1 (./dbg) started
New process p1 (program dbg) created
p1.1 SUSPENDED [D main in dbg.d]
78: main(string[] args)
dbg list 175
Source listing for thread p1.1, program dbg
175: if (srcpath !is null)
176: dv_dbgSrcpath(srcpath);
177: if (sympath !is null)
178: dv_dbgSympath(sympath);
179: auto cmd = new Command(uiType);
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
181: if (dbgrc is null)
182: {
183: dbgrc = homedir ~ / ~ DBGRC_FILE;
184: cmd.rc_exec(dbgrc);// home dir dbgrc
dbg run -u 179
p1.1 SUSPENDED [D main in dbg.d]
179: auto cmd = new Command(uiType);
dbg step -o
p1.1 STEPPED [D main in dbg.d]
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
dbg help
Run help on the following topics to get additional help.
Start Stop:
create, grab, quit, release, %follow, %srcpath, %sympath
Execution:
halt, jump, kill, run, step, wait, %thread
Events:
events, onstop, signal, stop, syscall, %lastevent,
%thisevent
View or Modify:
dump, list, maps, print, regs, set, stack, status, symbols,
vars, which
%dbg_lang, %file, %frame, %func, %lang, %line, %list_file,
%list_line,
%loc, %num_lines
Convenience:
!, alias, help, logoff, logon, script, %cwd, %logfile,
%log_prefix,
%prompt, %result, %verbose
For a full list of help topics, run help toc.
dbg help create
SYNOPSIS:
create [-f follow] [-l] [-s srcpath] [-S sympath]
[shell_cmd_string]
DESCRIPTION:
Create a new debugging session for shell_cmd_string. The
existing debug
sessions are not affected by this command. One could
simultaneously
have multiple debug sessions. If shell_cmd_string is not
specified, the
shell_cmd_string from previous create command is used and
the previous
create session is destroyed. After the session is created,
this command
runs all the processes till their 'start' function.
OPTIONS:
-ffollow 'prog', 'proc', 'thread' or 'all' or 'none'
-lload only; do not run new program / thread till its
'start' function
-spaths for source files
-Spaths for debug symbol files
NOTES:
It is not possible to redirect or pipe the output of create
command.
EXAMPLES:
create test_prog1 arg1 arg2 2/tmp/prog1.err | test_prog2
# creates a new debug session for test_prog1 and
test_prog2
create MANPAGER=more man 1p man
create xterm -e ./cmd
SEE ALSO:
events, quit, kill, release, run, shell_cmd_string, status,
step
%dbg_follow, %dbg_srcpath, %dbg_sympath, %follow, %srcpath,
%sympath
dbg
Without the nasty line-wrapping: http://pastebin.com/1Z4T4vep
woops, missed a couple: http://pastebin.com/t0sejnF9
Re: New debugger for D!!!
On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote: I'm planning to release a new debugger for D sometime during end of February. This is a heads up for all those who are eagerly looking for a good debugger for D. Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-)
Re: DUB 0.9.21 beta 3
On Monday, 27 January 2014 at 12:14:37 UTC, Sönke Ludwig wrote: I understand that it is popular because a separate source or src folder can be avoided*. But it really is quite unclean considering how importing modules works in D. * and it makes it harder for people to find the actual source code Yes, I agree. Dirk was the last project I created that uses this hierarchy (created in November 2010). It's a problem of scalability - the `libev`, `ssl` and `loader` packages were added long after the `irc` package.
Re: So, You Want To Write Your Own Programming Language?
On Monday, 27 January 2014 at 09:19:25 UTC, Kagamin wrote: On Thursday, 23 January 2014 at 10:24:23 UTC, Chris wrote: A good example are headlines. A classic is Driver refused license. Now, everybody will assume that it was not the driver who refused the license (default assumption or the _unmarked case_). Why it's not a driver who refused a license? More likely that it's a driver who was refused a license by the State (because of some reason such as you've been caught drinking and driving 20 times so you're totally banned). People aren't offered licenses and accept or reject them, they must seek them out. It doesn't make sense for someone to walk up (or be given a ride to by a friend) to the DMV wait 30 minutes and once they do all the work to get the license say Wait, no, I refuse this after all. So, despite Driver refused license possibly meaning the driver refused to accept the license despite being able to or driver was refused a license by the State (due to some circumstance), it's massively more likely to be the latter.
Re: New debugger for D!!!
On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote: On Monday, 27 January 2014 at 16:42:14 UTC, Sarath Kodali wrote: I'm planning to release a new debugger for D sometime during end of February. This is a heads up for all those who are eagerly looking for a good debugger for D. Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-) Ditto to these. I'm planning a project that will need a multi platform debugger, and would love to learn more about this.
Re: New debugger for D!!!
On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote: Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-) Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support for other 64 bit OSes and compilers. I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! Thanks for the interest, Sarath
Re: New debugger for D!!!
On Monday, 27 January 2014 at 17:13:05 UTC, John Colvin wrote: Without the nasty line-wrapping: http://pastebin.com/1Z4T4vep woops, missed a couple: http://pastebin.com/t0sejnF9 Thanks!
Re: New debugger for D!!!
On 1/27/14 7:00 PM, Sarath Kodali wrote: On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote: Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-) Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support for other 64 bit OSes and compilers. I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! Thanks for the interest, Sarath This does sound very interesting - and don't forget to submit a talk on the topic to DConf!!! Andrei
Re: New debugger for D!!!
Am 28.01.2014 04:00, schrieb Sarath Kodali: I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! why don't ease the IDE integration even more - for example the pin tool from intel (ptools.org) is a normal executable (the server) but you can give pin a tool/commander dll per commandline which is then responsible for controling the debugger - this way its very easy to integrate the debugger into any environment fast and performant examples pin.exe -t idadbg.dll - starts pin with an IDA-tool-dll to be able to control pin with the ida debugger pin.exe -t vsdbg.dll - starts pin with an vs-studio debug helper this way you can use pin as an debugger for VStudio etc. csv and json is nice - but there a much nicer ways of doing ipc
David Nadlinger (klickverbot) gets $150 bounty
Please join me in congratulating David! https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function/claims Don't forget there are over $2000 in open bounties for The D Programming Language project. More money is on the way if we make good progress on those! https://www.bountysource.com/trackers/383571-d-programming-language Andrei
Re: David Nadlinger (klickverbot) gets $150 bounty
On Tuesday, 28 January 2014 at 06:49:53 UTC, Andrei Alexandrescu wrote: Please join me in congratulating David! https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function/claims Don't forget there are over $2000 in open bounties for The D Programming Language project. More money is on the way if we make good progress on those! https://www.bountysource.com/trackers/383571-d-programming-language Andrei Good that we fixed that now, as 2.065 also contains a massive improvement to attribute inference (courtesy of Kenji), so this neat little feature will probably become more prominent going forwards. Thanks David :)
Re: New debugger for D!!!
On Tuesday, 28 January 2014 at 05:19:13 UTC, Andrei Alexandrescu wrote: This does sound very interesting - and don't forget to submit a talk on the topic to DConf!!! Andrei Yes please, it would be a very interesting talk.
