Re: std.Algebraic alias this
On Tuesday, 6 October 2015 at 06:37:16 UTC, Nicholas Wilson wrote: On Monday, 5 October 2015 at 11:31:32 UTC, Radu wrote: There is a weird rule on how compiler treats alias this for the N and S types bellow. [...] Please file a bug report. Also do the errors change if you reverse the order in T i.e. alias T = Algebraic!(S,N); ? OK, will do. Nope alias T = Algebraic!(S,N) gives the same error. AllowedTypes are (string, N) This happens in 2.068.2 btw
Re: SysTime bug or feature?
On Tuesday, 6 October 2015 at 05:54:44 UTC, Jonathan M Davis wrote: It is by design, albeit undesirable. When SysTime was originally written, it was impossible to have a default value for a class reference other than null. So, unless SysTime was going to take the performance hit of constantly checking whether its TimeZone was null, SysTime.init was going to segfault if you did anything with it that required its TimeZone. And I wasn't about to have it constantly checking for null. In the vast majority of cases, the value of a SysTime comes from Clock.currTime() or from parsing a string, and if code is trying to do anything but assign to a SysTime which is SysTime.init, then that means that it failed to initialize it like it should have. Thanks for thorough explanation. I found the problem using vibe and REST API with SysTime argument with default value (which didn't work due to the bug there) when I tried to print out the passed value and ended up with the segfault. So I guess it doesn't bite devs often as it is mostly used as you wrote.
Re: std.Algebraic alias this
On Monday, 5 October 2015 at 11:31:32 UTC, Radu wrote: There is a weird rule on how compiler treats alias this for the N and S types bellow. [...] Please file a bug report. Also do the errors change if you reverse the order in T i.e. alias T = Algebraic!(S,N); ?
Re: SysTime bug or feature?
On Monday, October 05, 2015 18:12:06 tchaloupka via Digitalmars-d-learn wrote:
> This code:
>
> import std.stdio;
> import std.datetime;
>
> void main()
> {
> SysTime t = SysTime.init;
> writeln(t);
> }
>
> results in segfault with dmd-2.068.2
>
> Is it ok?
It is by design, albeit undesirable. When SysTime was originally written, it
was impossible to have a default value for a class reference other than
null. So, unless SysTime was going to take the performance hit of constantly
checking whether its TimeZone was null, SysTime.init was going to segfault
if you did anything with it that required its TimeZone. And I wasn't about
to have it constantly checking for null. In the vast majority of cases, the
value of a SysTime comes from Clock.currTime() or from parsing a string, and
if code is trying to do anything but assign to a SysTime which is
SysTime.init, then that means that it failed to initialize it like it should
have.
At some point in the last couple of years, it became possible to directly
initialize a class reference that was a member variable (or static, or at
module level, etc.) with an immutable class object. So, when the issue that
you're bringing up was brought up last year, I tried to create a new
TimeZone class that would specifically be for SysTime.init so that
SysTime.init would still be unique (so that st is SysTime.init would still
work properly), and it would print out "SysTime.init" for toString and be
treated as 1-01-01T00:00:00+00:00 for most everything else, but a
compiler bugs with regards to Rebindable made it so that it didn't work.
I need to take another stab at it and see if it works now, but until the
compiler issue is resolved, SysTime.init will continue to segfault if you do
anything with it which requires its TimeZone to be used (which includes
toString).
- Jonathan M Davis
Re: Concatenation of ubyte[] to char[] works, but assignation doesn't
On Monday, October 05, 2015 11:48:51 Marc Schütz via Digitalmars-d-learn wrote: > On Monday, 5 October 2015 at 10:30:02 UTC, Jonathan M Davis wrote: > > On Monday, October 05, 2015 09:07:34 Marc Schütz via > > Digitalmars-d-learn wrote: > >> I don't think math would be a problem. There are some obvious > >> rules that would likely just work with most existing code: > >> > >> char + int = char > >> char - int = char > >> char - char = int > >> char + char = ERROR > > > > That depends on whether VRP can figure out that the result will > > fit. Otherwise, you'd be stuck with int. As it stands, all of > > these would just end up with int, I believe, though if they're > > assigned to a char and the int is a constant, then VRP may kick > > in and make a cast unnecessary. > > > > I think Walter's argument for allowing the int <-> char > conversions was that they are necessary to allow arithmetic. My > rules show that it works without these implicit conversions. > > VRP is a different problem, though. AFAICS, in the following > code, VRP either is smart enough, or it isn't, no matter whether > char implicitly converts to int. > > int diff = 'a' - 'A'; > char c = 'A'; > char d = c + diff; Your suggestion only works by assuming that the result will fit in a char, which doesn't fit at all with how coversions are currently done in D. It would allow for narrowing conversions which lost data. And there's no way that Walter would go for that (and I don't think that he should). VRP solves the problem insofar as it can guarantee that the result will fit in the target type and thus reduces the need for casting, but simply assuming that char + int will fit in a char just doesn't work unless we're going to allow narrowing conversions to lose data, which we aren't. If we were to allow the specific conversions that you're suggesting but only when VRP was used, then that could work, though it does make the implicit rules even screwier, becauses it becomes very dependent on how the int that you're trying to assign to a char was generated in the first place (straight assignment wouldn't work, but '0' - 40 would, whereas 'a' + 500 wouldn't, etc.). VRP already makes it a bit funky as it is, though mostly in a straightforward manner. - Jonathan M Davis
Re: AWS API Dlang, hmac sha256 function.
On 06/10/15 11:26 AM, holo wrote:
On Monday, 5 October 2015 at 21:00:38 UTC, Vladimir Panteleev wrote:
On Monday, 5 October 2015 at 19:43:39 UTC, holo wrote:
@Vladimir where can i check or do you know when next version of
phobos will be available?
You can use Digger to get the latest version of D:
https://github.com/CyberShadow/Digger
Thank you, now it is working as expected. Hope i wont miss upgrade in my
system to uninstall digger version before.
[holo@ultraxps workplace]$ cat ./hmac.d
#!/usr/bin/rdmd
import std.stdio;
import std.digest.sha, std.digest.hmac;
import std.string : representation;
void main()
{
auto hmac = hmac!SHA256("secretkey".representation);
hmac.put("texttohash".representation);
auto digest = hmac.finish();
writeln(digest);
}
[holo@ultraxps workplace]$ ./hmac.d
[28, 169, 142, 131, 133, 104, 149, 47, 205, 215, 20, 154, 170, 148, 84,
170, 252, 36, 10, 119, 18, 25, 10, 145, 183, 133, 135, 252, 26, 124,
215, 6]
[holo@ultraxps workplace]$ dmd --version
DMD64 D Compiler v2.069-devel-5e73c30
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
[holo@ultraxps workplace]$
Now need try to write some code which will connect me to AWS api based
on examples.
Congrats on getting it working!
Re: AWS API Dlang, hmac sha256 function.
On Monday, 5 October 2015 at 21:00:38 UTC, Vladimir Panteleev
wrote:
On Monday, 5 October 2015 at 19:43:39 UTC, holo wrote:
@Vladimir where can i check or do you know when next version
of phobos will be available?
You can use Digger to get the latest version of D:
https://github.com/CyberShadow/Digger
Thank you, now it is working as expected. Hope i wont miss
upgrade in my system to uninstall digger version before.
[holo@ultraxps workplace]$ cat ./hmac.d
#!/usr/bin/rdmd
import std.stdio;
import std.digest.sha, std.digest.hmac;
import std.string : representation;
void main()
{
auto hmac = hmac!SHA256("secretkey".representation);
hmac.put("texttohash".representation);
auto digest = hmac.finish();
writeln(digest);
}
[holo@ultraxps workplace]$ ./hmac.d
[28, 169, 142, 131, 133, 104, 149, 47, 205, 215, 20, 154, 170,
148, 84, 170, 252, 36, 10, 119, 18, 25, 10, 145, 183, 133, 135,
252, 26, 124, 215, 6]
[holo@ultraxps workplace]$ dmd --version
DMD64 D Compiler v2.069-devel-5e73c30
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
[holo@ultraxps workplace]$
Now need try to write some code which will connect me to AWS api
based on examples.
Re: Threading Questions
On Monday, 5 October 2015 at 20:18:18 UTC, Laeeth Isharc wrote: On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote: You may be right. I wrote a simple download manager in D using message passing. It was a little awkward at first, but in general, the spawn/send/receive API seems very intuitive. It feels awkward because the data you're working with is out of reach, but I guess it's safer that way. Any possibility of a blog post on your experience of doing so ? ;) [I should start writing some directly, but for time being, until I have my blog up and running again, I write from time to time on Quora]. A few minutes of writing now and then can have a remarkably big impact as well as clarifying your own thoughts, and the time invested is amply repaid, even viewed from a narrowly self-interested perspective. Unfortunately, my time is limited right now. I do have another project, which I've decided will either be finished or discarded by the dawn of 2016. So in the near future, I should have more time for other things. I had same experience with learning message passing. Feels like learning to eat with chopsticks in the beginning, but soon enough it feels much more civilised when it's the right tool for the job. I like the way my Worker class works because when I don't need the thread anymore, I can simply discard the object that represents the thread. As long as the Worker object is higher up on the stack than anything it's working on, all is well, and the concept of spawn/join is not visible while programming. This works out ok, because while the jobs I'm doing are slow enough to make a UI thread lag, they aren't long-running enough to where waiting for the Worker's thread to join in the destructor becomes a problem. There may be a small lag as the Worker's destructor waits for the last job to finish and the thread to join, but it's only happens once in the lifetime of the worker, so it's not a big deal. If care is not taken, the above could be subject to these problems: 1) shared memory corruption 2) worker accessing dead memory if it's placed on the stack below what it's working on 3) queueing a long running task could freeze the program on ~Worker() If you're moving or copying data into a thread, then returning the result(which can be ignored) I think most of the above can be solved. It's still a bit foreign to me though, and C++ has no such construct yet afaik. I read a bit about std::future and so on, but I'm not sure if they're standard yet. The biggest blocker though, is that the project I'm using that Worker class in is a Unity3D plugin. They only very recently updated their iOS libs to allow libc++ > 98 Bit
Re: implementing Ketmar's concept of a debugging console in D (Lua/PyD + arsd terminal-emulator)
On Monday, 5 October 2015 at 19:57:21 UTC, Laeeth Isharc wrote: Adam's work on terminal is quite nice - runs on Linux and Windows (maybe OSX) and it has mouse support and you can display images inline, which can be useful for some purposes. Command history and easy to add shortcuts. The terminal.d works on Mac with limited support as of last weekend (well, full support (minus my extensions) if you install xterm, but limited in the MacOS Terminal because its feature set is poor), but my terminal emulator does not - again, unless you install X11, then it should, because simpledisplay's cocoa implementation is currently broken. But I got a loaner Mac this week and should have it for a while, so I'll port simpledisplay to cocoa sometime in the next month, and then terminalemulator should work fully there too.
Re: AWS API Dlang, hmac sha256 function.
On Monday, 5 October 2015 at 19:43:39 UTC, holo wrote: @Vladimir where can i check or do you know when next version of phobos will be available? You can use Digger to get the latest version of D: https://github.com/CyberShadow/Digger
Re: Threading Questions
On 10/5/15 1:40 PM, bitwise wrote: On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote: On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn wrote: Since D is moving towards a phobos with no GC, what will happen to things that are classes like Condition and Mutex? Phobos and druntime will always use the GC for some things, and some things just plain need classes. Rather, we're trying to make it so that Phobos does not use the GC when it doesn't need to use the GC as well reduce how much the GC is required for stuff like string processing where lazy ranges can be used instead in many cases. I was under the impression that the idea was to _completely_ eliminate the GC. It says in Andre's 2015H1 vision statement: "We aim to make the standard library usable in its entirety without a garbage collector." No, the plan is to allow the user to choose how he wants to allocate. Many pieces of phobos make the assumption that the GC is fair game. I think the plan is to make those pieces instead allocate on the stack and provide a mechanism to move that allocation to the GC (Walter's Dconf talk was about this), or accept an allocator to use as a mechanism for allocating memory. -Steve
Re: Threading Questions
On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote: You may be right. I wrote a simple download manager in D using message passing. It was a little awkward at first, but in general, the spawn/send/receive API seems very intuitive. It feels awkward because the data you're working with is out of reach, but I guess it's safer that way. Any possibility of a blog post on your experience of doing so ? ;) [I should start writing some directly, but for time being, until I have my blog up and running again, I write from time to time on Quora]. A few minutes of writing now and then can have a remarkably big impact as well as clarifying your own thoughts, and the time invested is amply repaid, even viewed from a narrowly self-interested perspective. I had same experience with learning message passing. Feels like learning to eat with chopsticks in the beginning, but soon enough it feels much more civilised when it's the right tool for the job.
implementing Ketmar's concept of a debugging console in D (Lua/PyD + arsd terminal-emulator)
Development environments are very personal, and perhaps it's just
my age and not always wanting to learn what the kids are using
today, but I personally find strategic writeflns more helpful
than an IDE for debugging. Still, there comes a point when that
isn't enough.
Ketmar mentioned that he creates a debugging console that he
telnets in to where he can inspect state and perhaps modify it.
(And he shared the base version, which he put into public domain).
http://forum.dlang.org/post/mailman.210.1412254777.9932.digitalmar...@puremagic.com
"most of my reasonably complex
software has well-hidden interactive console inside, so i can
connect
to it to inspect the internal state and execute some (sometimes
alot ;-) of internal commands. and i must say that integrating
such
console in C projects was tiresome. with D i can do it almost
automatically, skipping annoying "variable registration" and
wrappers
for functions."
"some naming conventions and one mixin -- and all interesting
variables and functions from the given module are automatically
registered in command console. so i can inspect and change
variables and fields, call free functions and class/struct member
functions, even write simple scripts. it's really handy. and i
connect to this console using telnet (if telnet support is
activated).
this also allows some forms of unified "automated testing" even
for GUI apps, all without building special "debug versions", i.e.
on production code."
"it supports UDA annotations for getting help ('cmd ?'),
variables and free functions. and please don't blame me, that was
the first 'serious' code i did in D, learning D as i writting the
module. ;-)"
Ketmar - I just wanted to thank you for sharing this idea. Like
so many creative insights it's obvious in hindsight and I was
kind of getting there anyway via playing with Adam Ruppe's
terminal emulator (and his Inspector app built on top of it) and
John Colvin's work on putting D in the Jupyter notebook. But it
made it much more vivid as to what it should look like.
It may not be your cup of tea, but it seems to me that running
Lua (or Python) inside a console can be a beautifully simple way
to implement this without having to write lots of code for a
custom inspector. Adam's work on terminal is quite nice - runs
on Linux and Windows (maybe OSX) and it has mouse support and you
can display images inline, which can be useful for some purposes.
Command history and easy to add shortcuts.
Since LuaD (or PyD + pretty PyD) automatically wrap D types,
there is no need to do much more to be able to inspect what's
going on (perhaps a pretty printer and some way for the script
bit to interrupt your loop and get data within relevant scope if
you haven't set a 'breakpoint' by calling the debugger from
within your code - but you would need to do that anyway).
I'm still learning Lua, and not yet very familiar with LuaD. At
the moment it segfaults on Lua exceptions - possibly because I
set the panic handler wrong, because of some incompatibility with
LuaJit (which in theory is just a drop-in for Lua), or am doing
something stupid.
But the basic idea seems very handy, and you don't need to do
anything to wrap most D types.
Gist here - just my own proof of concept to convince myself, and
it doesn't do much. (I commented out the mouse code for now, and
the display of results from Lua is just on top line, which you
may not want):
https://gist.github.com/Laeeth/086419b7c67d2d6f29db
If you type return(tests[1]["date"]) at the command line then you
will see the D struct value - no manual wrapping involved. and
easy to call a D pretty printer etc - just add the function to
the lua state (see examples).
You can see how to make better use of the terminal by looking at
Ruppe's JSON inspector (also a very useful project) here:
https://github.com/adamdruppe/inspector/blob/master/inspect.d
LuaD docs and code here:
https://jakobovrum.github.io/LuaD/index.html
http://github.com/JakobOvrum/LuaD
Terminal code here:
https://github.com/adamdruppe/terminal-emulator
But perhaps some others may find this obvious in hindsight but
very useful approach useful for debugging.
Laeeth.
Re: AWS API Dlang, hmac sha256 function.
On Saturday, 3 October 2015 at 23:58:39 UTC, Rikki Cattermole wrote: On 04/10/15 2:31 AM, holo wrote: On Saturday, 3 October 2015 at 12:50:58 UTC, Rikki Cattermole wrote: On 04/10/15 1:49 AM, holo wrote: On Saturday, 3 October 2015 at 12:22:11 UTC, Rikki Cattermole wrote: On 04/10/15 1:09 AM, holo wrote: [...] By the looks of things the problem is with SHA256, I'm guessing it doesn't have its block size defined. https://github.com/D-Programming-Language/phobos/blob/master/std/digest/digest.d#L394 You'll also need to update sha.d as well. Otherwise it looks good. I updated sha.d and now im getting following error: $ ./app.d /usr/include/dlang/dmd/std/digest/sha.d(225): Error: pure function 'std.digest.sha.SHA!(512u, 160u).SHA.transform' cannot call impure function 'core.cpuid.ssse3' /usr/include/dlang/dmd/std/digest/digest.d(285): Error: template instance std.range.primitives.isOutputRange!(SHA!(512u, 160u), const(ubyte)[]) error instantiating /usr/include/dlang/dmd/std/digest/digest.d(851): instantiated from here: isDigest!(SHA!(512u, 160u)) /usr/include/dlang/dmd/std/digest/sha.d(1179):while looking for match for WrapperDigest!(SHA!(512u, 160u)) Failed: ["dmd", "-v", "-o-", "./app.d", "-I."] And one more file (ssse3.d) needs to be updated. You are going to be playing whack a mole I think for a while. I downloaded whole master branch phobos and tried to use it (changed path in dmd.conf), but there are missing much more files (i think that master branch is not ready yet). So i get back to my original library and tried to updated file you mention. But i can't find it (ssse3.d), its not appearing in my stable lib and even in that master-branch from zip file. Apologies, I didn't see this till after I got to bed. It's core.cpuid not ssse3.d. It will be in druntime, not Phobos. Sorry i was busy at weekend. Thank you all for answers. I will try to write some solution basing on yawniek example and will back if some troubles appears. @Vladimir where can i check or do you know when next version of phobos will be available? @Rikki i downloaded both master zip files for runtime and phobos librarys all dependencies looks are satisfied right now but still getting errors: [holo@ultraxps workplace]$ dmd hmac.d hmac.o: In function `_D3std6digest4hmac58__T4hmacTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4hmacFNaNbNiNfMAxhZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC': hmac.d:(.text._D3std6digest4hmac58__T4hmacTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4hmacFNaNbNiNfMAxhZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC+0x18): undefined reference to `_D3std6digest3sha20__T3SHAVki512Vki160Z3SHA6__initZ' hmac.o: In function `_D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC6__ctorMFNaNbNcNiNfMAxhZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC': hmac.d:(.text._D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC6__ctorMFNaNbNcNiNfMAxhZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC+0x1b): undefined reference to `_D3std6digest3sha20__T3SHAVki512Vki160Z3SHA5startMFNaNbNiNfZv' hmac.d:(.text._D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC6__ctorMFNaNbNcNiNfMAxhZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC+0x31): undefined reference to `_D3std6digest3sha20__T3SHAVki512Vki160Z3SHA3putMFNaNbNiNeMAxhXv' hmac.d:(.text._D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC6__ctorMFNaNbNcNiNfMAxhZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC+0x3e): undefined reference to `_D3std6digest3sha20__T3SHAVki512Vki160Z3SHA6finishMFNaNbNiNeZG20h' hmac.o: In function `_D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC5startMFNaNbNcNiNjNfZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC': hmac.d:(.text._D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC5startMFNaNbNcNiNjNfZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC+0x8d): undefined reference to `_D3std6digest3sha20__T3SHAVki512Vki160Z3SHA5startMFNaNbNiNfZv' hmac.d:(.text._D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC5startMFNaNbNcNiNjNfZS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC+0xa4): undefined reference to `_D3std6digest3sha20__T3SHAVki512Vki160Z3SHA3putMFNaNbNiNeMAxhXv' hmac.o: In function `_D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC3putMFNaNbNcNiNjNfxAhXS3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki160Z3SHAVmi512Z4HMAC': hmac.d:(.text._D3std6digest4hmac58__T4HMACTS3std6digest3sha20__T3SHAVki512Vki1
SysTime bug or feature?
This code:
import std.stdio;
import std.datetime;
void main()
{
SysTime t = SysTime.init;
writeln(t);
}
results in segfault with dmd-2.068.2
Is it ok?
Backtrace:
#0 0x004733f3 in std.datetime.SysTime.adjTime() const ()
#1 0x004730b9 in std.datetime.SysTime.toSimpleString()
const ()
#2 0x00473339 in std.datetime.SysTime.toString() const ()
#3 0x00463dc4 in
std.format.formatObject!(std.stdio.File.LockingTextWriter,
std.datetime.SysTime, char).formatObject(ref
std.stdio.File.LockingTextWriter, ref std.datetime.SysTime, ref
std.format.FormatSpec!(char).FormatSpec) ()
#4 0x00463cb7 in
std.format.formatValue!(std.stdio.File.LockingTextWriter,
std.datetime.SysTime,
char).formatValue(std.stdio.File.LockingTextWriter, ref
std.datetime.SysTime, ref
std.format.FormatSpec!(char).FormatSpec) ()
#5 0x00463c5a in
std.format.formatGeneric!(std.stdio.File.LockingTextWriter,
std.datetime.SysTime,
char).formatGeneric(std.stdio.File.LockingTextWriter,
const(void)*, ref std.format.FormatSpec!(char).FormatSpec)---Type
to continue, or q to quit---
()
#6 0x00463b63 in
std.format.formattedWrite!(std.stdio.File.LockingTextWriter,
char,
std.datetime.SysTime).formattedWrite(std.stdio.File.LockingTextWriter, const(char[]), std.datetime.SysTime) ()
#7 0x00463675 in
std.stdio.File.write!(std.datetime.SysTime,
char).write(std.datetime.SysTime, char)
()
#8 0x00463591 in
std.stdio.writeln!(std.datetime.SysTime).writeln(std.datetime.SysTime) ()
#9 0x00461b38 in D main ()
Re: Threading Questions
On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote:
On Sunday, October 04, 2015 14:42:48 bitwise via
Digitalmars-d-learn wrote:
Since D is moving towards a phobos with no GC, what will
happen to things that are classes like Condition and Mutex?
Phobos and druntime will always use the GC for some things, and
some things just plain need classes. Rather, we're trying to
make it so that Phobos does not use the GC when it doesn't need
to use the GC as well reduce how much the GC is required for
stuff like string processing where lazy ranges can be used
instead in many cases.
I was under the impression that the idea was to _completely_
eliminate the GC. It says in Andre's 2015H1 vision statement:
"We aim to make the standard library usable in its entirety
without a garbage collector."
I understand the allocation/freeing of memory is expensive, but I
thought the actual sweep of the GC was a problem too, and that
disabling the GC to avoid the sweep was the plan for some people.
I don't know how long D's GC takes to sweep, but even a 5ms pause
would be unacceptable for a performance intensive game.
I guess if you use @nogc properly though, you could still safely
turn off the GC, right?
As for Condition and Mutex specifically, I don't know whey they
were ever classes except perhaps to take advantage of the
monitor in Object. Maybe they'll get changed to structs, maybe
they won't, but most D code is thread-local, and most of the
code that isn't is going to use message passing, which means
that explicit mutexes and conditions are unnecessary. So, most
code won't be impacted regardless of what we do with Condition
and Mutex.
You may be right. I wrote a simple download manager in D using
message passing. It was a little awkward at first, but in
general, the spawn/send/receive API seems very intuitive. It
feels awkward because the data you're working with is out of
reach, but I guess it's safer that way.
Regardless, I doubt that anything will be done with Condition
or Mutex until shared is revisted, which is supposed to happen
sometime soon but hasn't happened yet. What happens with shared
could completely change how Condition and Mutex are handled
(e.g. they don't support shared directly even though they
should probably have most of their members marked with shared,
because Sean Kelly didn't want to be doing anything with shared
that he'd have to change later).
- Jonathan M Davis
I'm not sure what's going to be done with shared, but I do think
it's annoying that you can't do this:
shared Array!int numbers;
someThread... {
numbers.clear(); // 'clear' is not shared
}
So this means that on top of the already ridiculous number of
attributes D has, now you have to mark everything as shared too =/
Bit
Re: Concatenation of ubyte[] to char[] works, but assignation doesn't
On Monday, 5 October 2015 at 10:30:02 UTC, Jonathan M Davis wrote: On Monday, October 05, 2015 09:07:34 Marc Schütz via Digitalmars-d-learn wrote: I don't think math would be a problem. There are some obvious rules that would likely just work with most existing code: char + int = char char - int = char char - char = int char + char = ERROR That depends on whether VRP can figure out that the result will fit. Otherwise, you'd be stuck with int. As it stands, all of these would just end up with int, I believe, though if they're assigned to a char and the int is a constant, then VRP may kick in and make a cast unnecessary. I think Walter's argument for allowing the int <-> char conversions was that they are necessary to allow arithmetic. My rules show that it works without these implicit conversions. VRP is a different problem, though. AFAICS, in the following code, VRP either is smart enough, or it isn't, no matter whether char implicitly converts to int. int diff = 'a' - 'A'; char c = 'A'; char d = c + diff;
std.Algebraic alias this
There is a weird rule on how compiler treats alias this for the N
and S types bellow.
As you can see, somehow S losses it's type and ends up a plain
string withing the Algebraic type. I would expect that all types
should be the treated the same, why a string alias will be
different then a bool or a double?
int main(string[] argv)
{
import std.variant : Algebraic;
struct N { double val; alias val this; }
struct S { string val; alias val this; }
alias T = Algebraic!(N, S);
pragma(msg, T.AllowedTypes); // prints (N, string)??
T t = N(1.0);
assert(t.get!N == 1.0); // works
// t = 0.4; // fails, OK, variant.d(586): Error: static assert
"Cannot store a double in a VariantN!(8u, N, S). Valid types are
(N, string)"
// t = S("foo"); // this fails, why? Error: static assert
"Cannot store a S in a VariantN!(8u, N, S). Valid types are (N,
string)"
t = "bar"; // this works... why?
// assert(t.get!S == "bar"); //this fails Variant: attempting to
use incompatible types immutable(char)[] and main.main.S at
std\variant.d(1475)
assert(t.get!string == "bar"); // works, why?
return 0;
}
Re: Online Phobos Prerelease Docs
On Monday, 5 October 2015 at 09:53:09 UTC, Per Nordlöw wrote: On Monday, 5 October 2015 at 08:45:54 UTC, John Colvin wrote: http://dlang.org/phobos/index.html it's on the sidebar I can't find allocator there (yet) in tree. http://dlang.org/phobos-prerelease/std_experimental_allocator.html Why? because the website needs updating. In the mean-time, `digger build --with=website`
Re: Online Phobos Prerelease Docs
On Monday, 5 October 2015 at 10:46:20 UTC, John Colvin wrote: I can't find allocator there (yet) in tree. http://dlang.org/phobos-prerelease/std_experimental_allocator.html Why? because the website needs updating. In the mean-time, `digger build --with=website` Ahh, nice!
Re: Concatenation of ubyte[] to char[] works, but assignation doesn't
On Monday, October 05, 2015 09:07:34 Marc Schütz via Digitalmars-d-learn wrote:
> On Sunday, 4 October 2015 at 21:57:44 UTC, Jonathan M Davis wrote:
> > On Sunday, October 04, 2015 16:13:47 skilion via
> > Digitalmars-d-learn wrote:
> >> Is this allowed by the language or it is a compiler bug ?
> >>
> >> void main() {
> >> char[] a = "abc".dup;
> >> ubyte[] b = [1, 2, 3];
> >> a = b; // cannot implicitly convert expression (b) of
> >> type
> >> ubyte[] to char[]
> >> a ~= b; // works
> >> }
> >
> > When appending, b to a, the elements in b are being copied onto
> > the end of a, and presumably it works in this case, because a
> > ubyte is implicitly convertible to char. But all it's doing is
> > converting the individual elements. It's not converting the
> > array.
> >
> > On other hand, assigning b to a would require converting the
> > array, and array types don't implicitly convert to one another,
> > even if their elements do.
> >
> > Honestly, I think that the fact that the character types
> > implicitly convert to and from the integral types of the
> > corresponding size is problematic at best and error-prone at
> > worst, since it almost never makes sense to do something like
> > append a ubyte to string. However, if it didn't work, then
> > you'd have to do a lot more casting when you do math on
> > characters, which would cause its own set of potential bugs.
> > So, we're kind of screwed either way.
>
> I don't think math would be a problem. There are some obvious
> rules that would likely just work with most existing code:
>
> char + int = char
> char - int = char
> char - char = int
> char + char = ERROR
That depends on whether VRP can figure out that the result will fit.
Otherwise, you'd be stuck with int. As it stands, all of these would just
end up with int, I believe, though if they're assigned to a char and the int
is a constant, then VRP may kick in and make a cast unnecessary.
But discussions on whether types like char, wchar, dchar or bool should be
treated like integral types can get interesting. Walter clearly favors
treating them as integral types where as a number of us would much prefer
that they weren't. But both sides of the argument can show where the other
side's desired behavior would be problematic.
- Jonathan M Davis
Re: Online Phobos Prerelease Docs
On Monday, 5 October 2015 at 09:04:17 UTC, Marc Schütz wrote: Example: http://dtest.thecybershadow.net/results/222c23bc3a5255fff85139b32277a6b9c0402815/ca92fc9f966c135b895f305595aaf43a4e66872d/ Thanks!
Re: Online Phobos Prerelease Docs
On Monday, 5 October 2015 at 08:45:54 UTC, John Colvin wrote: http://dlang.org/phobos/index.html it's on the sidebar I can't find allocator there (yet) in tree. http://dlang.org/phobos-prerelease/std_experimental_allocator.html Why?
Re: Online Phobos Prerelease Docs
On Monday, 5 October 2015 at 08:45:54 UTC, John Colvin wrote: http://dlang.org/phobos/index.html it's on the sidebar That was too easy. Thanks!
Re: Concatenation of ubyte[] to char[] works, but assignation doesn't
On Sunday, 4 October 2015 at 21:57:44 UTC, Jonathan M Davis wrote:
On Sunday, October 04, 2015 16:13:47 skilion via
Digitalmars-d-learn wrote:
Is this allowed by the language or it is a compiler bug ?
void main() {
char[] a = "abc".dup;
ubyte[] b = [1, 2, 3];
a = b; // cannot implicitly convert expression (b) of
type
ubyte[] to char[]
a ~= b; // works
}
When appending, b to a, the elements in b are being copied onto
the end of a, and presumably it works in this case, because a
ubyte is implicitly convertible to char. But all it's doing is
converting the individual elements. It's not converting the
array.
On other hand, assigning b to a would require converting the
array, and array types don't implicitly convert to one another,
even if their elements do.
Honestly, I think that the fact that the character types
implicitly convert to and from the integral types of the
corresponding size is problematic at best and error-prone at
worst, since it almost never makes sense to do something like
append a ubyte to string. However, if it didn't work, then
you'd have to do a lot more casting when you do math on
characters, which would cause its own set of potential bugs.
So, we're kind of screwed either way.
I don't think math would be a problem. There are some obvious
rules that would likely just work with most existing code:
char + int = char
char - int = char
char - char = int
char + char = ERROR
Re: Online Phobos Prerelease Docs
On Monday, 5 October 2015 at 08:19:26 UTC, Per Nordlöw wrote: Is there an (official or unoffical) prerelease version of the Phobos docs, typically for studying std.allocator? It would be nice to have the D servers auto-generate this every time a PR is merged into druntime/phobos. In each PR at the bottom there is a CI section with links to the auto-tester, Travis and Vladimir Panteleev's documentation tester. The latter generates the documentation and makes it viewable online: Example: http://dtest.thecybershadow.net/results/222c23bc3a5255fff85139b32277a6b9c0402815/ca92fc9f966c135b895f305595aaf43a4e66872d/
Re: Online Phobos Prerelease Docs
On Monday, 5 October 2015 at 08:19:26 UTC, Per Nordlöw wrote: Is there an (official or unoffical) prerelease version of the Phobos docs, typically for studying std.allocator? It would be nice to have the D servers auto-generate this every time a PR is merged into druntime/phobos. http://dlang.org/phobos/index.html it's on the sidebar
Re: How to break gdb on D exception ?
On Sunday, 4 October 2015 at 14:31:43 UTC, BBasile wrote: On Friday, 2 October 2015 at 09:15:13 UTC, Dmitri wrote: On Friday, 2 October 2015 at 04:50:59 UTC, BBasile wrote: On Friday, 2 October 2015 at 04:46:51 UTC, BBasile wrote: On Friday, 2 October 2015 at 04:24:11 UTC, Adam D. Ruppe wrote: On Friday, 2 October 2015 at 03:58:45 UTC, BBasile wrote: none of the following GB commands work: give break d_throw or maybe `break d_throwc` a try unfortunately it doesn't work, i get --- (gdb) Function "d_throw"/"d_throwc" not defined. it was almost that actually, 'break _d_throwc Or you could break on a specific exception class's constructor. This would be better. 1/ because I could propose a modifiable list of the exception kinds to track in the options). 2/ because with _d_trow_c, info stack #1 is really not interesting. #2 or #3 is usually where the 'thing' really happens. How can I do that, for example with FileException class ? Well, you look it up: info func FileException 0x005ff7c4 std.file.FileException.this(const(char[]), const(char[]), immutable(char)[], ulong) 0x005ff89c std.file.FileException.this(const(char[]), uint, immutable(char)[], ulong) 0x006139ec std.stream.StreamFileException.this(immutable(char)[]) and then set either via a name or an address: b std.file.FileException.this or b *0x5ff7c4 with the difference that the name version potentially sets multiple breakpoints and moves it just after the frame setup code.
Online Phobos Prerelease Docs
Is there an (official or unoffical) prerelease version of the Phobos docs, typically for studying std.allocator? It would be nice to have the D servers auto-generate this every time a PR is merged into druntime/phobos.
Re: Posix termios
On Monday, October 05, 2015 05:58:32 Alexander via Digitalmars-d-learn wrote: > Is it just me, or is not posix termios.h implemented in phobos? > (git), I am looking at core.sys.linux.termios but all I get there > is a few enums(B57600, B115200, etc..)? There's a core.sys.posix.termios and core.sys.linux.termios. It looks like most of the implementation is in core.sys.posix.termios, and core.sys.linux.termios publicly imports it. - Jonathan M Davis
