Re: DGui is alive
20.05.2014 17:46, FrankLike пишет: DGui need some other controls,such as imageButton,DataView,GridViewe.t.c. There is no plan to add new controls and I don't see any lacking ones. One can use `paint` event to draw image on button and there is `GridPanel` (with usage example `grid.d`) so I don't understand why `GridView` is needed and what is its purpose. Also I don't know what is `DataView` for. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: dbox is a complete D2 port of the Box2D game physics library
On Friday, 23 May 2014 at 22:52:53 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: On 5/24/14, Piotrek via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: nice one. How does it compare to C++ version in terms of performance? I haven't tested the performance yet! I'm definitely interested, but as usual I assume LDC will probably beat DMD in this area. Do you intend to keep this a straight port or will it be open to modifications? From a brief look at the source, it's possible I'll end up needing turning shapes from classes to structs and/or hooking it up with a custom allocator. I expect to need to spawn/destroy objects of varying shapes very often. (I do plan to try the current version first, though; it may be good enough) If I make such changes (which may affect the API, although the changes can probably be kept somewhat small), should I open a pull request or start a fork (ddbox? ;p)? (Same question applies to other of your ports)
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 11:04:58 UTC, Vladimir Panteleev wrote: http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ Some highlights from a recent overhaul of the graphics package from my D library. It makes use of a number of D-specific language features, so I've tried to make the article accessible to people new to D as well. The graphics package described in Vladimir's post has been separated in a stand-alone DUB package here: https://github.com/p0nce/ae-graphics
Re: dbox is a complete D2 port of the Box2D game physics library
On 5/24/14, Kiith-Sa via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Do you intend to keep this a straight port or will it be open to
modifications?
I think we can create a new branch with API improvements and
additions. I'm not sure what the state of dub support for this is,
apparently branch-based dependencies are now deprecated? I hope we can
do something like this:
# Use the direct C++ Port
dependencies: { dbox: =0.0.2, }
# Use a new D-ified interface which has more features
dependencies: { dbox: d_api:=0.0.2, }
Can we do something like this already with dub?
Andrei's allocators could come in very handy. I'm still unsure how we
can actually hook up a custom allocator, you can't really do things
like $ dmd -alias allocator = mymodule.myallocator.
As for actual behavioral changes, we better start adding unittests then. :)
Btw, there's a Contributions folder in the Box2D distribution which I
haven't ported, it has some cool features like fluids support. I'm not
sure if it's the same as the following video, but the stuff is cool:
https://www.youtube.com/watch?v=UKlkk3uCdJs
From a brief look at the source, it's possible I'll end up
needing turning shapes
from classes to structs and/or hooking it up with a custom
allocator.
I wanted to convert everything into structs, but the problem is the
C++ library used inheritance and virtual methods even though in the
end they end up using all of these objects as stack-allocated objects.
I'm not sure whether we actually have to spawn a lot of shape objects
though (AFAICT few of them ever get instantiated), but if that's true
then converting these to structs might be beneficial.
I expect to need to spawn/destroy objects of varying
shapes very often. (I do plan to try the current version first,
though; it may be good enough)
Good luck!
If I make such changes (which may affect the API, although the
changes can probably be kept somewhat small), should I open a
pull request or start a fork
(ddbox? ;p)?
We could create a new branch, but for the moment you're probably
better off not writing any pull requests since I will be MIA for a
while (I'm moving very soon). I'll keep you updated.
(Same question applies to other of your ports)
Same answer! :)
Re: DirectX bindings
On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d new additions: +Direct2D [DX9 state] (though still some helper functions missing) +DirectWrite [DX9 state] +DXGI [DX11.1, DX11.2] +Direct3D [DX11.1, DX11.2] examples: +Direct2D sample from MSDN ( a bit ugly at this moment )
Re: DConf 2013 Pictures
On 5/20/14, Ali Çehreli digitalmars-d-announce@puremagic.com wrote: I hope it's not too stale. :p http://acehreli.org/DConf_2013_Pictures/ Hope we won't have to wait a year for the DConf 2014 pictures! :) Have any been taken this year?
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On Friday, 23 May 2014 at 23:56:39 UTC, Adam D. Ruppe wrote: On Friday, 23 May 2014 at 19:59:23 UTC, Mattcoder wrote: Hehe, I'm just imagining what Walter will say: Lack of images! Heh, I actually went through a few idea stages here: 1) I'd list the druntime functions. I determined this to be boring and subject to change anyway. But I spent like a month without better ideas and it was too boring for me to even do... so yeah nothing got done. ... I liked your presentation as well. When you started talking about writing your Floppy Disk driver for your kernel without using BIOS or DOS, I remembered my 11 years ago days. Wish there was more time and you could continue.
Re: DConf 2013 Pictures
On 5/21/2014 12:18 AM, Ali Çehreli wrote: The size is 112M and unfortunately it is slow. It worked quickly for me. Thanks!
Re: DConf 2013 Pictures
On 5/20/2014 11:44 PM, Andrej Mitrovic via Digitalmars-d-announce wrote: This is great. But is there any way to download the pictures all at once? Yes, please!
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On Saturday, 24 May 2014 at 18:12:40 UTC, Tolga Cakiroglu wrote: When you started talking about writing your Floppy Disk driver for your kernel without using BIOS or DOS, Aye, programming on DOS was cool (and of course, so was programming without DOS too!) It is actually frustrating to know what the hardware can do then being limited by some abstraction or emulation that does less. This is why doing terminal work on Linux annoys me: the VT100 emulation is so much less capable than the plain old VGA hardware (or the X11 protocol, of course). That's one reason why I started making my own terminal emulator https://github.com/adamdruppe/terminal-emulator so I can do custom extensions to get some of this back. Key up notifications, easy output when jumping around, etc. Of course, my terminal.d library, like ncurses, can do a lot of that too, there's still the annoying underlying limitations that really don't have to be there. And good old mode 13h! But yeah, the floppy disk drive is fun too and doing that driver was something I played with a long time ago with 16 bit code, now that was something painful to get right too! Resetting and aligning the motor, etc., fun. Like I alluded to at the end though, my favorite part is the noise the drives make :) Real computers are noisy!
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On Saturday, 24 May 2014 at 00:36:31 UTC, John wrote: I wish there was more time available. My poor throat was getting dry near the end anyway... But I was kinda worried that I was getting too negative at times. My theme was supposed to be encouraging, go ahead and try it, and instead I started complaining about triple faults and ugly code. But oh well, the agony of defeat contributes to the thrill of victory after you finally make it work! And btw, you were looking great too! :) thanks! Part of that was that I wanted to be deliberately counter-culture. I almost never see anyone in these tech videos wearing a tie, and while in the facebook building I think I was the only one there too. (the irony, a conservative business suit is my anti-authoritarian apparel lolololol) Of course, that's not the /only/ reason I wore it, but it was a nice bonus.
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On Saturday, 24 May 2014 at 20:46:30 UTC, sclytrack wrote:
Were there actual slides?
Nope, I never actually got around to creating any.
I just had an outline on my desktop of stuff I was thinking about
creating, but just didn't finish it. The paper was my recreation
of that outline from memory.
Here's the outline.txt stuff I didn't mention on the paper btw:
* Replacing functions with the linker
* Reflection: Using RTInfo's lint to enforce ownership rules
(e.g. make it a compile time error to define a struct with a
mutable slice. This has a few pros and a lot of cons.)
* Doing a custom calling convention with naked functions and
mixins
* Talk about ABI details and the implementation of scope
statements (e.g. scope(exit). I briefly talked about it being
lowered to finally {} but didn't go into the asm like I was
considering
* The -betterC switch and what I want more from it.
Otherwise, my memory was pretty decent for remembering what I had
in mind! Then my random on-the-spot digressions padded out the
time.
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On Saturday, 24 May 2014 at 20:53:18 UTC, Adam D. Ruppe wrote:
On Saturday, 24 May 2014 at 20:46:30 UTC, sclytrack wrote:
Were there actual slides?
Nope, I never actually got around to creating any.
Okay, busy guy.
I just had an outline on my desktop of stuff I was thinking
about creating, but just didn't finish it. The paper was my
recreation of that outline from memory.
Here's the outline.txt stuff I didn't mention on the paper btw:
* Replacing functions with the linker
* Reflection: Using RTInfo's lint to enforce ownership rules
(e.g. make it a compile time error to define a struct with a
mutable slice. This has a few pros and a lot of cons.)
* Doing a custom calling convention with naked functions and
mixins
* Talk about ABI details and the implementation of scope
statements (e.g. scope(exit). I briefly talked about it being
lowered to finally {} but didn't go into the asm like I was
considering
* The -betterC switch and what I want more from it.
Otherwise, my memory was pretty decent for remembering what I
had in mind! Then my random on-the-spot digressions padded out
the time.
I would have preferred slides though. I'm not so good at
listening. The visual impact helps ME better at remembering.
Yeah, your memory is fine.
:-)
Re: DConf 2013 Pictures
On 05/24/2014 05:49 AM, Andrej Mitrovic via Digitalmars-d-announce wrote: On 5/20/14, Ali Çehreli digitalmars-d-announce@puremagic.com wrote: I hope it's not too stale. :p http://acehreli.org/DConf_2013_Pictures/ Hope we won't have to wait a year for the DConf 2014 pictures! :) Have any been taken this year? David Ellsworth and others took many pictures. I hope they don't bother with post processing and show us the pictures soon. ;) Ali
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On 5/24/2014 3:49 PM, Adam D. Ruppe wrote: thanks! Part of that was that I wanted to be deliberately counter-culture. I almost never see anyone in these tech videos wearing a tie, and while in the facebook building I think I was the only one there too. (the irony, a conservative business suit is my anti-authoritarian apparel lolololol) It seems a very Talking Heads irony, I like it :)
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On Saturday, 24 May 2014 at 21:01:13 UTC, sclytrack wrote: I would have preferred slides though. I'm not so good at listening. The visual impact helps ME better at remembering. Yea, they were on my todo list, I was just too lazy and/or distracted to do it. But I'm not sure they would have been really informational anyway; I think a talk is a terrible way to deliver information and one of the reasons I was stalled/procrastinating on this is I didn't have a good solution to that problem. If I want to deliver info, I'd prefer to do it in writing such as emails, blogs or traditional code documentation. (The best idea I had to work around this deficiency was to script it ahead of time with supporting photographs or occasional data tables to give you an associated image to remember the concept, and post the script along with any supporting material to the 'net later. But I didn't know how many words would fit in an hour and writing a script is a pain anyway so my laziness kicked in.) But ultimately, I decided my primary goal wasn't to deliver information but to instead sell a feeling so you might be stirred to try some new things on your own.
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On 5/24/2014 3:41 PM, Adam D. Ruppe wrote: And good old mode 13h! Real programmers used Mode X! (I mainly used 13h though ;) )
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On Saturday, 24 May 2014 at 23:47:58 UTC, Nick Sabalausky wrote: Real programmers used Mode X! Yea! ...I never really got into it tho and kept going back to 13 for the plain simplicity.
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On 5/24/2014 3:49 PM, Adam D. Ruppe wrote: thanks! Part of that was that I wanted to be deliberately counter-culture. I almost never see anyone in these tech videos wearing a tie, and while in the facebook building I think I was the only one there too. (the irony, a conservative business suit is my anti-authoritarian apparel lolololol) My favorite way to be counter-culture is to use slang terms in unexpected contexts. Like using a meme to make a point on a very technical topic. Or more commonly, well gee, I think deadpan delivery of anachronistic slang is just swell, dawg. Bonus pizzoints for mixing all those swingin' tubular eras...I really can dig that (Again, deadpan delivery be paramount). Or concocting me up some pluralities of formalism levels. Similarly, mixed cussing is golly good f**king fun. Word. (I really do like to deliberately use outdated slang, and the more deadpan the better.)
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On 5/25/2014 1:18 AM, Nick Sabalausky wrote: Similarly, mixed cussing is golly... s/golly/jolly/ Ugh...
Re: Thank you Kenji
On 5/22/2014 9:11 PM, Martin Nowak wrote: Today at DConf we learned, once again, that people are doing and starting amazing projects using D. A lot of which wouldn't have been possible without your contribution. So I just wanted to say thank you. Yes, and I want to add that Kenji always takes on the hard problems to solve!
Re: Thank you Kenji
23.05.2014 8:11, Martin Nowak пишет: Today at DConf we learned, once again, that people are doing and starting amazing projects using D. A lot of which wouldn't have been possible without your contribution. So I just wanted to say thank you. -Martin Finally a thread to thank the man who fights all these corner cases and bugs. ) Thank you Kenji very much! -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Associative Arrays max length? 32bit/64bit
Bloody Thunderbird. I think I pressed Reply instead of Followup. Sorry, Steven.
On 2014-05-19 15:31, Steven Schveighoffer wrote:
No, in that DMD file, the bucket is a tree, not a doubly-linked list.
Silly me. A look at the body of delnodes should have made it clear that it's a
binary tree.
opCmp is not used in D's AA.
Really? Then what does TypeInfo.compare(void*, void*) use? For example here:
auto key_hash = keyti.getHash(pkey); Entry *e;
/* ... */
if (key_hash == e.hash) {
auto c = keyti.compare(pkey, e + 1);
if (c == 0) goto Lret;
}
Suggestion/proposal regarding std.logger candidate
Yesterday, in the livestream chat, there was some discussion about
the current std.logger proposal. The consensus seemed to be that
it's probably fine for most use cases and it's the best proposal
we've had so far, it doesn't look suitable for heavy duty,
enterprise-grade logging. In an ideal world, the std.logger
module
in phobos would be flexible enough to build an enterprise-grade
logging library on top of, but it seems the current proposal isn't
there yet. I got to thinking about how to make the logging system
more flexible, and this is what I came up with.
I identified three key parts to a logger: the filter, the format,
and the sink.
log.trace(...) Filter Format Sink
The filter determines which log messages to act on, and which to
ignore. Usually this is done based on the log level, but one use
case that was brought up was automatically sending an email to the
developers only when a particular exception occurred (i.e. filter
based on Exception type). Currently, std.logger implements the
filtering for you, based on the global log level, and the log
level
of that particular logger.
The format determines what the output of the log message looks
like.
Usually, this winds up being some sort of call to formattedWrite,
though there is no need to assume that the output must be a
string,
or even human-readable. Currently, formatting tends to be
implemented as part of Logger.writeLogMsg, and is specific to each
Logger implementation.
The sink is where the log message goes. Popular destinations
include stderr, /dev/null, some text file somewhere, or a central
logging facility provided by your OS. Currently, the sink is
specified when implementing Logger.writeLogMsg.
Based on these three parameters, I came up with the following
proof
of concept implementation, built on top of the current proposal:
public class Clogger(alias format, alias filter, Sink) : Logger
if( isLogFilter!filter isLogFormat!format
isLogSink!(Sink, format) )
{
public this(Sink sink, string newName, LogLevel lv) {
super(newName, lv);
this.sink = sink;
}
override
public void writeLogMsg(ref LoggerPayload payload) {
import std.algorithm : copy;
if( this.filterFun(payload) ) {
sink = formatFun(payload).copy(sink);
}
}
private:
Sink sink;
alias formatFun = unaryFun!format;
alias filterFun = unaryFun!filter;
}
The full code is at https://github.com/krendil/clogger.
As you can see, there are three template parameters, that
correspond
to the three components identified above.
- filter is a predicate that takes a LoggerPayload and returns
true
if that log message should be logged.
- format takes a LoggerPayload and converts it to something
suitable for output, in the form of a Range.
- Sink is an OutputRange that has the same element type as the
the output of format.
I think there are a few benefits to this setup:
- Separation of format from sink
- Custom, arbitrary filtering
- Simpler to implement new Loggers
With this setup, multiplexing can either be done at the Logger
level, as it is currently, or at the Sink level. Log messages can
still be converted to any sort of output. Aliases or convenience
functions could be created for common Logger types (I currently
have
convenience functions for a multiplexer, a stdout logger and a
generic dchar range logger).
Destroy :)
Re: Suggestion/proposal regarding std.logger candidate
Just to be clear, what I am suggesting/proposing is that the current Logger class in std.logger be altered so that it looks more like this, with filter, format and sink template arguments that determine its behaviour, instead of using an inheritance-based approach.
Re: Suggestion/proposal regarding std.logger candidate
The logger is very good and need thing. But has anybody an idea how to preserve purity of functions?
Re: Suggestion/proposal regarding std.logger candidate
On Saturday, 24 May 2014 at 10:04:33 UTC, David Osborne wrote: Just to be clear, what I am suggesting/proposing is that the current Logger class in std.logger be altered so that it looks more like this, with filter, format and sink template arguments that determine its behaviour, instead of using an inheritance-based approach. Please be aware of KISS, YAGNI and other beware of over engineering principles
Re: Suggestion/proposal regarding std.logger candidate
On Saturday, 24 May 2014 at 11:58:35 UTC, Gary Willoughby wrote: On Saturday, 24 May 2014 at 10:04:33 UTC, David Osborne wrote: Just to be clear, what I am suggesting/proposing is that the current Logger class in std.logger be altered so that it looks more like this, with filter, format and sink template arguments that determine its behaviour, instead of using an inheritance-based approach. Please be aware of KISS, YAGNI and other beware of over engineering principles Why not just copy the design of boost::log?
Re: Including Dub with D
Am 23.05.2014 08:24, schrieb Jacob Carlborg: On 22/05/14 21:11, Nick Sabalausky wrote: Is there anything blocking actual adoption of SDL? I'm not holding anything up am I? Sonke: If there's anything you need done/dealt-with regarding SDLang-D, let me know. No, SDLang-D is absolutely fine, it's just me being overloaded with other things. Do we want/need the SDL parser/writer to be included into Phobos first? I'd include it as a git subtree into the repository, so that this wouldn't be necessary. This copy would only used when building DUB using the build.sh/.cmd. When DUB itself is used as a package/library, it would use the sdlang-d DUB package instead.
Thanks for a great DConf
Hello all, Just to say a big thank you to everyone speaking and involved in the organization of DConf this year. It was fantastic to be able to follow the conference via livestreaming (as much as timezones allowed:-), and the ideas and projects on display were full of excitement and inspiration. Here's looking forward to another great year of D and even more exciting projects at next year's conference! Best wishes, -- Joe
Re: Including Dub with D
On Fri, May 23, 2014 at 7:39 AM, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: Original thread : http://forum.rejectedsoftware. com/groups/rejectedsoftware.dub/thread/2/ Summary by Sonke: https://github.com/rejectedsoftware/dub/wiki/Sdl- based-package-format-draft Thanks. Personally, I don't find the arguments for switching convincing. Perhaps moving to an extended JSON that supports comments and other niceties, but moving to an entirely new format seems excessive. The nice thing about JSON is that it is commonly used everywhere, making dub easy to approach and easy to write tooling for - even after a switch to SDL as the primary format, I can see many folks and tooling continuing to use JSON. Without removal of JSON support you are stuck supporting two formats... tl;dr I think it is a bad idea.
Re: Including Dub with D
On Saturday, 24 May 2014 at 16:42:32 UTC, Jeremy Powers via Digitalmars-d wrote: On Fri, May 23, 2014 at 7:39 AM, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: Original thread : http://forum.rejectedsoftware. com/groups/rejectedsoftware.dub/thread/2/ Summary by Sonke: https://github.com/rejectedsoftware/dub/wiki/Sdl- based-package-format-draft Thanks. Personally, I don't find the arguments for switching convincing. Perhaps moving to an extended JSON that supports comments and other niceties, but moving to an entirely new format seems excessive. The nice thing about JSON is that it is commonly used everywhere, making dub easy to approach and easy to write tooling for - even after a switch to SDL as the primary format, I can see many folks and tooling continuing to use JSON. Without removal of JSON support you are stuck supporting two formats... tl;dr I think it is a bad idea. I don't really see the point of it either. A reason for switching doesn't jump out at me.
Re: Including Dub with D
On 5/24/2014 12:42 PM, Jeremy Powers via Digitalmars-d wrote: On Fri, May 23, 2014 at 7:39 AM, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: Original thread : http://forum.rejectedsoftware. com/groups/rejectedsoftware.dub/thread/2/ Summary by Sonke: https://github.com/rejectedsoftware/dub/wiki/Sdl- based-package-format-draft Thanks. Personally, I don't find the arguments for switching convincing. Perhaps moving to an extended JSON that supports comments and other niceties, but moving to an entirely new format seems excessive. The nice thing about JSON is that it is commonly used everywhere, making dub easy to approach and easy to write tooling for - even after a switch to SDL as the primary format, I can see many folks and tooling continuing to use JSON. Without removal of JSON support you are stuck supporting two formats... tl;dr I think it is a bad idea. Nobody has said anything about removing JSON support. It's been stated that JSON support is *staying* as an option. SDL will merely be the recommended format. Sayeth Sonke: The plan is to keep full support for the JSON based package description and still use it for machine-to-machine communication, but at the same time add the new format as the preferred way for developers to write. - https://github.com/rejectedsoftware/dub/wiki/Sdl-based-package-format-draft
Re: Thanks for a great DConf
On 5/24/2014 11:26 AM, Joseph Rushton Wakeling via Digitalmars-d wrote: Hello all, Just to say a big thank you to everyone speaking and involved in the organization of DConf this year. It was fantastic to be able to follow the conference via livestreaming (as much as timezones allowed:-), and the ideas and projects on display were full of excitement and inspiration. Here's looking forward to another great year of D and even more exciting projects at next year's conference! Best wishes, -- Joe ///ditto ;) I'm in DConf withdrawal right now. Three straight days of livestreamed talks and fun live chats...it doesn't feel right not to have that today! BTW, a huge thanks for offering a live stream! It's no substitute for being there, of course, but it's a great next-best-thing for those of us who wanted to attend but couldn't. I'm looking forward to the YouTube reruns for the talks I still missed. (I still can't believe I missed Andrei's keynote!)
Re: isUniformRNG
On 5/23/2014 3:43 PM, Joseph Rushton Wakeling via Digitalmars-d wrote: OK, so let's run with the idea that at some point crypto RNGs will be a submodule of std.random. So to recap my understanding of it: An initial PR for Hash_DRBG being struct-based and directly part of std.random, and then the submodule and conversion to class being part of your std.random2?
Re: Including Dub with D
On Sat, May 24, 2014 at 10:30 AM, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: Nobody has said anything about removing JSON support. It's been stated that JSON support is *staying* as an option. SDL will merely be the recommended format. Yes - my point is that moving to SDL while keeping JSON just means you now have two formats you need to support. This will likely have the effect of fragmenting things, with any tooling needing to support both.
Re: Including Dub with D
On 5/24/2014 10:15 AM, Sönke Ludwig wrote: Am 23.05.2014 08:24, schrieb Jacob Carlborg: On 22/05/14 21:11, Nick Sabalausky wrote: Is there anything blocking actual adoption of SDL? I'm not holding anything up am I? Sonke: If there's anything you need done/dealt-with regarding SDLang-D, let me know. No, SDLang-D is absolutely fine, it's just me being overloaded with other things. Do we want/need the SDL parser/writer to be included into Phobos first? I'd include it as a git subtree into the repository, so that this wouldn't be necessary. This copy would only used when building DUB using the build.sh/.cmd. When DUB itself is used as a package/library, it would use the sdlang-d DUB package instead. Ok, sounds good to me. But maybe I should put a std.sdlang through the phobos review queue to help getting DUB into the standard DMD releases?
auto-tester hardware donations
As discussed a little at the conference, the auto-tester is almost always hardware bound. In other words, it's building flat out 24/7. More hardware == faster updates to build status. If anyone wants to provide hardware to help there's a number of ways to do so. Here's my order of preference: 1) you have a machine you host somewhere and can provide me remote access to. - this could be a bare metal host or a vm 2) you have a machine that you're willing to send to me 3) you're willing to fund equipment purchase or vm rental At this point, I'd MUCH rather have hardware that doesn't live in my house. I've got too many already. But I also don't want to turn down good equipment. So, please reach out to me privately if you'd like to help out: bra...@puremagic.com Thanks, Brad
Re: Including Dub with D
On Saturday, 24 May 2014 at 17:30:54 UTC, Nick Sabalausky wrote: On 5/24/2014 12:42 PM, Jeremy Powers via Digitalmars-d wrote: On Fri, May 23, 2014 at 7:39 AM, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: Original thread : http://forum.rejectedsoftware. com/groups/rejectedsoftware.dub/thread/2/ Summary by Sonke: https://github.com/rejectedsoftware/dub/wiki/Sdl- based-package-format-draft Thanks. Personally, I don't find the arguments for switching convincing. Perhaps moving to an extended JSON that supports comments and other niceties, but moving to an entirely new format seems excessive. The nice thing about JSON is that it is commonly used everywhere, making dub easy to approach and easy to write tooling for - even after a switch to SDL as the primary format, I can see many folks and tooling continuing to use JSON. Without removal of JSON support you are stuck supporting two formats... tl;dr I think it is a bad idea. Nobody has said anything about removing JSON support. It's been stated that JSON support is *staying* as an option. SDL will merely be the recommended format. Sayeth Sonke: The plan is to keep full support for the JSON based package description and still use it for machine-to-machine communication, but at the same time add the new format as the preferred way for developers to write. - https://github.com/rejectedsoftware/dub/wiki/Sdl-based-package-format-draft That is not the issue. The issue is with tools, e.g. an IDE or script wanting to support Dub will have to have a dependency on an SDL parser (while pretty much every language has a JSON parser in its standard lib and if not a parser can be written in a few hours - on the other hand SDL is very uncommon at the moment). So you can't e.g. write a quick python util script without requiring an external library.
Re: Including Dub with D
On 5/24/2014 1:54 PM, Jeremy Powers via Digitalmars-d wrote: On Sat, May 24, 2014 at 10:30 AM, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: Nobody has said anything about removing JSON support. It's been stated that JSON support is *staying* as an option. SDL will merely be the recommended format. Yes - my point is that moving to SDL while keeping JSON just means you now have two formats you need to support. This will likely have the effect of fragmenting things, with any tooling needing to support both. Not really. dub describe takes care of that. And (if it doesn't already) DUB really should also provide an API to directly query all a package's info, letting DUB handle all the parsing.
Re: Including Dub with D
Am 24.05.2014 20:34, schrieb Nick Sabalausky: On 5/24/2014 1:54 PM, Jeremy Powers via Digitalmars-d wrote: On Sat, May 24, 2014 at 10:30 AM, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: Nobody has said anything about removing JSON support. It's been stated that JSON support is *staying* as an option. SDL will merely be the recommended format. Yes - my point is that moving to SDL while keeping JSON just means you now have two formats you need to support. This will likely have the effect of fragmenting things, with any tooling needing to support both. Not really. dub describe takes care of that. And (if it doesn't already) DUB really should also provide an API to directly query all a package's info, letting DUB handle all the parsing. Exactly, the recommended way to work with package descriptions is always to use dub describe, or to use DUB as a library, which enables working with packages on several abstraction levels. There are a lot of package features that need to be supported and it doesn't really make much sense to try and reimplement all of that in every IDE - especially as long as the format isn't 100% stable.
Re: Including Dub with D
Am 24.05.2014 19:51, schrieb Nick Sabalausky: But maybe I should put a std.sdlang through the phobos review queue to help getting DUB into the standard DMD releases? Not sure if that would be really considered necessary, but I wouldn't mind that for sure in general* (I think it should be enough if the repository doesn't have external dependencies). But please let's try to establish something like std.data.sdl, so that the top level std package doesn't get ever more crowded when new formats get added. * It may also be a good step to solve the chicken-egg issue here, where the argument is that because SDL isn't so common, it shouldn't be used. I think it's a really nice little format that deserves to get some support.
Re: Suggestion/proposal regarding std.logger candidate
On Sat, May 24, 2014 at 2:57 AM, David Osborne via Digitalmars-d digitalmars-d@puremagic.com wrote: Destroy :) Overall, this approach seems good. Not sure I like forcing one format for all sinks though - it is often desired/necessary to have different sinks (aka appenders) format the log messages differently. Aside: I'd recommend anyone looking at logging examine the logback architecture, if they haven't already: http://logback.qos.ch/manual/architecture.html Not saying std.logger should look like this, but shows one fairly well thought out solution.
Re: Thanks for a great DConf
On Saturday, 24 May 2014 at 17:40:29 UTC, Nick Sabalausky wrote: I'm looking forward to the YouTube reruns for the talks I still missed. (I still can't believe I missed Andrei's keynote!) +1 please.
Re: isUniformRNG
On 24/05/14 19:46, Nick Sabalausky via Digitalmars-d wrote: An initial PR for Hash_DRBG being struct-based and directly part of std.random I think that's up to you. I don't want to hold you back here, but equally, I feel that crypto functionality probably should be prototyped in an experimental module before being finalized in the standard library. It's something that's too important to get right (and properly reviewed).
Re: To deadalnix
On 05/24/2014 05:03 AM, Joshua Niehus wrote: watching your talk was like witnessing Fermats last theorem being proven... the scheduler solution was brilliant and the semantic analysis of a mixin statement that resulted in a comprehensible error message blew my mind. Here is a belated applause that should have happened during those slides. Well done. josh Unfortunately, I missed the talk. Sounds promising (I'm using an explicit scheduler component for semantic analysis as well.) What does comprehensible mixin error message mean exactly?
Re: Thanks for a great DConf
On Saturday, 24 May 2014 at 20:34:03 UTC, monarch_dodra wrote: On Saturday, 24 May 2014 at 17:40:29 UTC, Nick Sabalausky wrote: I'm looking forward to the YouTube reruns for the talks I still missed. (I still can't believe I missed Andrei's keynote!) +1 please. me too. +1
Re: Associative Arrays max length? 32bit/64bit
On Sat, 24 May 2014 02:54:01 -0700, FG h...@fgda.pl wrote:
Bloody Thunderbird. I think I pressed Reply instead of Followup. Sorry,
Steven.
It's OK, it went into my spam folder anyway ;)
On 2014-05-19 15:31, Steven Schveighoffer wrote:
No, in that DMD file, the bucket is a tree, not a doubly-linked list.
Silly me. A look at the body of delnodes should have made it clear that
it's a binary tree.
opCmp is not used in D's AA.
Really? Then what does TypeInfo.compare(void*, void*) use? For example
here:
auto key_hash = keyti.getHash(pkey); Entry *e;
/* ... */
if (key_hash == e.hash) {
auto c = keyti.compare(pkey, e + 1);
if (c == 0) goto Lret;
}
You know what, you are right. I assumed it used keyti.equals. This is a
bug imo, since opCmp will be used, and opEquals will be ignored. Just
checking for opCmp == 0 is identical to opEquals, except some types can
define opEquals but not opCmp.
But I don't know if it will get fixed. The whole AA runtime has to be
redone at some point.
-Steve
Re: Thanks for a great DConf
I've watched all transmissions and I liked 'em all (without any exception). And I think the end of the conference should be a beginning of the new trend here. So instead of wait for DConf 2015, all those speakers should do more videos (at home etc.) sharing their thoughts. Matheus.
Re: To deadalnix
On 05/24/2014 03:58 PM, Timon Gehr wrote: What does comprehensible mixin error message mean exactly? deadalnix showed a piece of code that had a compilation error inside a mixin string that was mixed in by another mixin. The compiler was pointing out the exact column of the mixed in error, as well as all the inclusion backtrace. Ali
Re: Suggestion/proposal regarding std.logger candidate
On Sat, 24 May 2014 11:42:30 + HaraldZealot via Digitalmars-d digitalmars-d@puremagic.com wrote: The logger is very good and need thing. But has anybody an idea how to preserve purity of functions? That's impossible if you're doing I/O. By definition, that has to access mutable, global state. The only way to do it would be to go the Haskell route and use something like monads - you'd have to basically pass an object around which built up the logging messages without actually logging anything and then have an impure function higher up (which is calling these pure functions) make the function call which actually caused the queued up logging to be output. Logging is basically anti-purity. So, unless you do something like I just described (which I doubt much of anyone will), then logging anything in your code means giving up purity. - Jonathan M Davis
Re: To deadalnix
On 5/24/2014 10:41 PM, Ali Çehreli wrote: On 05/24/2014 03:58 PM, Timon Gehr wrote: What does comprehensible mixin error message mean exactly? deadalnix showed a piece of code that had a compilation error inside a mixin string that was mixed in by another mixin. The compiler was pointing out the exact column of the mixed in error, as well as all the inclusion backtrace. DAT DIAGNOSTIC! o_O
Re: Associative Arrays max length? 32bit/64bit
On Sat, May 24, 2014 at 06:05:49PM -0700, Steven Schveighoffer via
Digitalmars-d wrote:
On Sat, 24 May 2014 02:54:01 -0700, FG h...@fgda.pl wrote:
[...]
Really? Then what does TypeInfo.compare(void*, void*) use? For
example here:
auto key_hash = keyti.getHash(pkey); Entry *e;
/* ... */
if (key_hash == e.hash) {
auto c = keyti.compare(pkey, e + 1);
if (c == 0) goto Lret;
}
You know what, you are right. I assumed it used keyti.equals. This is
a bug imo, since opCmp will be used, and opEquals will be ignored.
Just checking for opCmp == 0 is identical to opEquals, except some
types can define opEquals but not opCmp.
But I don't know if it will get fixed. The whole AA runtime has to be
redone at some point.
[...]
This has been argued over in a druntime pull before. I'm 100% for
changing the above line (and all other instances of it) to use
keyti.equals() instead. But that was shot down due to potential breakage
of existing code. :-( :-( Nevermind the fact that it probably breaks a
lot more *new* code than it ever will break old code... :-(
It's been far too long that AA's have been broken in druntime. Somebody
should just take the aaA.d out in the back and shoot it, and replace it
with a better implementation. I think users will be far happier with
that.
T
--
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Kitchen Design Lancashire Reviews
Kitchen Design Lancashire Reviews. what a great kitchen and price Kitchen Design Lancashire Reviews can provide.
Re: Programming a Game in D? :D
On Thursday, 22 May 2014 at 15:39:36 UTC, David wrote: Hey, I'm really new to D, and pretty new to programming overall too, But I want to make a 3d Game, (just sth. small). I really like D and want to do it in D, but in the Internet there is no shit about programming a game in D ^^ Is there any engine written in D? For example the CryEngine is for C++, so I would have to write a wrapper? So, how do I write a wrapper? I would need a wrapper for DirectX too right? Are there any wrappers ore Engines for D i can use? btw. I know I dont write that in 1 day ^^ Are there any tutorials or sth. on Programming a Game in D? S I just wanna come as far to have a little Cube where i can run around on with a few phisics :) so just the startup to load a world and so on Thanks in advance :) And sry my english sucks :D Hi David, Learning programming, learning D and learning 3D are 3 significant endeavours. You might want to begin with http://www.basic4gl.net/ which will get you going with 3D, quite a topic in itself. Then learn D regardless :)
Re: Programming a Game in D? :D
On Friday, 23 May 2014 at 17:47:56 UTC, evilrat wrote: why not just use Xamarin Studio with Mono-D? But only the trial of Xamarin Studio is for free, and I used eclipse for Java before and really like it :P
Re: Programming a Game in D? :D
On Saturday, 24 May 2014 at 09:35:01 UTC, David wrote: On Friday, 23 May 2014 at 17:47:56 UTC, evilrat wrote: why not just use Xamarin Studio with Mono-D? But only the trial of Xamarin Studio is for free, and I used eclipse for Java before and really like it :P actually not. you don't even need to register at all. just go to http://monodevelop.com and get ur XS without all this fancy mobile stuff.
dmd with shared lib
Hi, after building and installing dmd i fail to use generated executable because they are an undefined symbol. $ /opt/dmd/bin/dmd -L-lcurl testDelegate.d $ ./testDelegate ./testDelegate: symbol lookup error: /opt/dmd/lib/libphobos2.so.0.66: undefined symbol: curl_version_info $ ldd ./testDelegate linux-vdso.so.1 = (0x7fff2d4e8000) libcurl.so.4 = /opt/dmd/lib/libcurl.so.4 (0x7f82fd06) libdl.so.2 = /lib64/libdl.so.2 (0x7f82fce58000) libphobos2.so.0.66 = /opt/dmd/lib/libphobos2.so.0.66 (0x7f82fc81) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f82fc5f) libm.so.6 = /lib64/libm.so.6 (0x7f82fc2e8000) librt.so.1 = /lib64/librt.so.1 (0x7f82fc0e) libc.so.6 = /lib64/libc.so.6 (0x7f82fbd2) /lib64/ld-linux-x86-64.so.2 (0x7f82fd288000) given executable is link with libcurl provided by dmd when i look into these curl lib they are any curl_version_info symbol # readelf -Ws /opt/dmd/lib/libcurl.so.4 | grep curl_version_info # readelf -Ws /opt/dmd/lib/libcurl_stub.so | grep curl_version_info while this symbol exist on libcurl provided by my fedora # readelf -Ws /usr/lib64/libcurl.so.4| grep curl_version_info 346: 00023f20 140 FUNCGLOBAL DEFAULT 11 curl_version_info
How to debug ?
OK, I have the newest Eclipse+DDT on Linux. Debugging capabilies look great : https://github.com/bruno-medeiros/DDT/blob/latest/documentation/Features.md#debugging-functionality However so far I haven't been able to step throug source code. What am I missing ? Is there an option to pass to the compiler ? Yet another tweak to json.dub ?
Re: How to debug ?
On Saturday, 24 May 2014 at 10:14:23 UTC, Derix wrote: OK, I have the newest Eclipse+DDT on Linux. Debugging capabilies look great : https://github.com/bruno-medeiros/DDT/blob/latest/documentation/Features.md#debugging-functionality However so far I haven't been able to step throug source code. What am I missing ? Is there an option to pass to the compiler ? Yet another tweak to json.dub ? Hi, To debug you nee to use -g flag to compiler I use cgdb to debug D programm it wrap gdb and have a syntax color for D. You need to take a recent cgdb version to get his D support
derelict glfw won't set callbacks
Any attempt to set callbacks in GLFW returns a null and the
callback doesn't work.
The first enforcement fails in this example:
DerelictGLFW3.load ();
enforce (glfwSetErrorCallback (error_callback));
enforce (glfwInit (), glfwInit failed);
window = glfwCreateWindow (screen_dims.x, screen_dims.y, sup,
null, null);
glfwMakeContextCurrent (window);
glfwSwapInterval (0);
If I forget about the callbacks, everything functions normally (I
can render, etc).
Here is error_callback:
static extern (C) void error_callback (int, const (char)* error)
nothrow {
import std.c.stdio: fprintf, stderr;
fprintf (stderr, error glfw: %s\n, error);
}
It is a static member function but pulling it out to the module
scope changes nothing.
It doesn't work when I do it from the main thread or a secondary
thread.
The load-set_error_callback-glfwInit sequence is recommended
everywhere I look up D's GLFW bindings, so apparently this works
for other people and I must be missing something.
And in the event that this can't be solved, I suppose the thing
to do is to either poll for input events manually or try to get
that part working in C then call it from D?
Re: derelict glfw won't set callbacks
On 5/24/14, Vlad Levenfeld via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Any attempt to set callbacks in GLFW returns a null and the
callback doesn't work.
The first enforcement fails in this example:
DerelictGLFW3.load ();
enforce (glfwSetErrorCallback (error_callback));
It's ok if this fails because this is how it's documented:
* @return The previously set callback, or `NULL` if no callback was set or an
* error occurred.
Below is a full snippet of using DerelictGLFW and a simple escape key binding:
-
import derelict.glfw3.glfw3;
import std.conv;
import std.exception;
import std.stdio;
shared static this()
{
DerelictGLFW3.load();
}
extern(C) void error_callback(int error, const(char)* description) nothrow
{
printf(%s %s, error, description);
}
int main()
{
/* Initialize the library */
enforce(glfwInit());
glfwSetErrorCallback(error_callback);
GLFWwindow* window;
/* Create a windowed mode window and its OpenGL context */
window = glfwCreateWindow(640, 480, Hello World, null, null);
scope(exit) glfwTerminate();
enforce(window !is null);
/* Make the window's context current */
glfwMakeContextCurrent(window);
extern(C) void onKeyEvent(GLFWwindow* window, int key, int
scancode, int state, int modifier) nothrow
{
if (key == GLFW_KEY_ESCAPE state == GLFW_PRESS)
glfwSetWindowShouldClose(window, true);
}
glfwSetKeyCallback(window, onKeyEvent);
/* Loop until the user closes the window */
while (!glfwWindowShouldClose(window))
{
/* Render here */
/* Swap front and back buffers */
glfwSwapBuffers(window);
/* Poll for and process events */
glfwPollEvents();
}
return 0;
}
-
Re: derelict glfw won't set callbacks
On Saturday, 24 May 2014 at 13:31:46 UTC, Vlad Levenfeld wrote:
Any attempt to set callbacks in GLFW returns a null and the
callback doesn't work.
The first enforcement fails in this example:
DerelictGLFW3.load ();
enforce (glfwSetErrorCallback (error_callback));
enforce (glfwInit (), glfwInit failed);
window = glfwCreateWindow (screen_dims.x, screen_dims.y, sup,
null, null);
glfwMakeContextCurrent (window);
glfwSwapInterval (0);
If I forget about the callbacks, everything functions normally
(I can render, etc).
Here is error_callback:
static extern (C) void error_callback (int, const (char)*
error) nothrow {
import std.c.stdio: fprintf, stderr;
fprintf (stderr, error glfw: %s\n, error);
}
It is a static member function but pulling it out to the module
scope changes nothing.
It doesn't work when I do it from the main thread or a
secondary thread.
The load-set_error_callback-glfwInit sequence is recommended
everywhere I look up D's GLFW bindings, so apparently this
works for other people and I must be missing something.
And in the event that this can't be solved, I suppose the thing
to do is to either poll for input events manually or try to get
that part working in C then call it from D?
glfwSetErrorCallback returns the previous callback, so it makes
sense null is returned on the first call.
Re: derelict glfw won't set callbacks
Haha, I should have read more carefully. Must have looked at that line in the doc a dozed times and never picked up on that detail. Your example worked for me - I wasn't calling glfwPollEvents. Thanks!
Upgrade woes : Eclipse/DDT/Linux , compile takes forever and other caveats
I'm on Linux 64-bit. I recently upgraded Eclipse to 4.3.2 and DDT
to 0.10.1 ... and at first I couldn't compile a thing anymore.
After googling some more, and burning a few more neurons, I
finally gathered some clues and narrowed the quest to the
dub.json file. I pieced together the following :
{
name : gtklessons,
description : A minimal D bundle.,
targetType : executable,
dependencies : {
gtk-d:gtkd: =2.3.1
}
}
which somehow enables the build to complete.
The keys here were the line
targetType : executable,
together with the dependencies section.
There still are a bunch of things I don't get. First, building
takes forever, even with a very simple and short source, where it
used to take an insignificant number of seconds.
Then, a whole bunch of files I didn't ask for poped up in my
userland, more or less the whole gtkd package, sources and all,
even though it is already installed on the system (namely
/usr/include/dmd/gtkd2/). There must be a more clever way.
Third, isn't there a way to set all this at the IDE or working
set level instead of project-by-project ?
And finally I find that the number of options that can and must
go in this dub.json file is way too high, and that said options
are somehow poorly documented. Are there some easy-access
reference out there ?
And oh, the reason I updated in the first place was that I
understood that debugging was better with the newest version of
DDT. I must have missed something here too, because I still
can't properly debug as in step-by-step in the source code. Any
hint ?
Re: How to debug ?
To debug you nee to use -g flag to compiler Thanks, but how ?
Re: Programming a Game in D? :D
On Saturday, 24 May 2014 at 09:49:30 UTC, evilrat wrote: why not just use Xamarin Studio with Mono-D? But only the trial of Xamarin Studio is for free, and I used eclipse for Java before and really like it :P actually not. you don't even need to register at all. just go to http://monodevelop.com and get ur XS without all this fancy mobile stuff. Hi. How I can debug in Xamarin? What I need do for activate debugger? I have this option is disabled: http://goo.gl/cDGIk1
foreach over string
foreach over string apparently iterates over chars by default instead of dchars. Didn't it prefer dchars? string s=weiß; int i; foreach(c;s)i++; assert(i==5);
Re: foreach over string
On 2014-05-24 12:46, Kagamin wrote: foreach over string apparently iterates over chars by default instead of dchars. Didn't it prefer dchars? string s=weiß; int i; foreach(c;s)i++; assert(i==5); A string is defined by: alias string = immutable(char)[]; It doesn't add anything to that type (unless you import a library like std.algorithm, which adds many methods thanks to UFCS and generic functions) I believe you are looking for dstring which is defined by: alias dstring = immutable(dchar)[]; dstring s=weiß; int i; foreach(c;s)i++; assert(i==4);
Creating ranges over mutable, const, or immutable data structures.
I have been writing my own hashmap which can provide forward ranges usable in @safe pure nothrow functions, because it's going to be useful for creating graph data structures with the same. I came to writing my ranges and I figured out how to do everything right for just mutable hashmaps, but I have no idea how to manage the tail-const nature of ranges in a variety of combinations. I figured out that I need to satisfy the following constraints. Create a mutable KeyRange over a map which forwards on the right constness for the key type, so the following must be true. HashMap!(K, V).keys.front - K const(HashMap!(K, V)).keys.front - const(K) immutable(HashMap!(K, V)).keys.front - immutable(K) I have encounted some difficulty in trying to write a range which does this.
How to handle try-catch blocks, nothrow and logfiles
I'm working on an application where I want log all exceptions but
I'm not sure what's the best way to realize that. Sure I can do
the following:
void myMethod() nothrow
{
try
{
// Do something
}
catch (Exception e)
{
// Write log file
}
}
But there are some problems:
1) try-catch are working great for local error handling. But
they are nearly useless for global error handling. Imagine I've
an application where I want log all thrown exceptions. Sure, I
can create a Logfile-class and log all exceptions in the
catch-block. But doing this in all my methods forces me to create
dirty code (more braces, more idents because of more braces, more
lines and so on...). Additionally when I change the interface of
my Logfile-class I need to adapt all catch-blocks. I think that's
not an optimal solution. So, is there anything I can use to log
all exceptions in one handler, for instance something like that:
void handleExceptions(Exception e)
{
// Write to log file
}
void myMethod() throwTo(handleExceptions)
{
// Call something that probably throws an exception
}
2) When I want create an application where all methods are
defined as nothrow - how can I realize that? Writing to a
log-file is already throwable. Yes, I can catch the exception and
write the same to the command line but that's also unsafe... are
there any nothrow-function to write a file or something to the
command line? It's a bit sad when I want log an exception and I'm
unable to write the log entry because something happened. So how
can make sure that I log all exceptions? Is that even possible?
Re: How to handle try-catch blocks, nothrow and logfiles
On 05/24/2014 10:09 AM, Tim wrote:
I'm working on an application where I want log all exceptions but I'm
not sure what's the best way to realize that.
A common solution is to log it in the exception class'es constructor. We
even dump the backtrace with libunwind in our C++ application.
However, you may quickly realize that not every thrown exception is
log-worthy. The reason is, e.g. a MyMissingFile exception may not be
important when there is a default action to follow. No need to log in
that case.
Just to note, although these are valid issues, exceptions are still the
best option for error handling.
Sure I can do the following:
void myMethod() nothrow
{
try
{
// Do something
}
catch (Exception e)
{
// Write log file
}
}
As you say, that does not scale. :)
2) When I want create an application where all methods are defined
as nothrow - how can I realize that? Writing to a log-file is already
throwable.
You can bypass the compiler by wrapping the throwing expression in
assumeWontThrow (as I have shown just yesterday during my DConf
lightning talk. How timely... :))
Contrary to its name assumeWontThrow throws an Error (not Exception) if
the expression actually throws.
// This function requires that the argument is less than 10
void bar(int i)
{
import std.exception : enforce;
enforce(i 10);
// ...
}
void foo() nothrow
{
import std.exception : assumeWontThrow;
// I know that bar(7) won't throw. So, it's
// safe to bypass the compiler in this case.
assumeWontThrow(bar(7));
/* Note: UFCS may look less natural:
*
* bar(7).assumeWontThrow;
*
* bar(7) is NOT executed before assumeWontThrow. Rather,
assumeWontThrow
* takes a lazy parameter. So, bar(7) is assumed to be nothrow.
*/
// ...
}
void main()
{
foo();
}
Ali
Re: foreach over string
On 05/24/2014 09:46 AM, Kagamin wrote: foreach over string apparently iterates over chars by default instead of dchars. Didn't it prefer dchars? I don't think so. The range algorithms iterate by dchar though. string s=weiß; int i; foreach(c;s)i++; assert(i==5); Ali
Re: Creating ranges over mutable, const, or immutable data structures.
On 05/24/2014 10:02 AM, w0rp wrote: I have been writing my own hashmap which can provide forward ranges usable in @safe pure nothrow functions, because it's going to be useful for creating graph data structures with the same. I came to writing my ranges and I figured out how to do everything right for just mutable hashmaps, but I have no idea how to manage the tail-const nature of ranges in a variety of combinations. I figured out that I need to satisfy the following constraints. Create a mutable KeyRange over a map which forwards on the right constness for the key type, so the following must be true. HashMap!(K, V).keys.front - K const(HashMap!(K, V)).keys.front - const(K) immutable(HashMap!(K, V)).keys.front - immutable(K) I have encounted some difficulty in trying to write a range which does this. How timely! :) Jonathan Crapuchettes talked about facing the same issue in his talk at DConf. Perhaps he will post his WrapMutability template here or you can wait for his talk on YouTube. Ali
Re: Programming a Game in D? :D
On Saturday, 24 May 2014 at 16:41:41 UTC, Dmitry wrote: On Saturday, 24 May 2014 at 09:49:30 UTC, evilrat wrote: why not just use Xamarin Studio with Mono-D? But only the trial of Xamarin Studio is for free, and I used eclipse for Java before and really like it :P actually not. you don't even need to register at all. just go to http://monodevelop.com and get ur XS without all this fancy mobile stuff. Hi. How I can debug in Xamarin? What I need do for activate debugger? I have this option is disabled: http://goo.gl/cDGIk1 there is a plugin for linux for GDB i believe, and another plugin for Windows which i can't remember the name, the latter one disappeared from XS 5.0 by some reason. search the extensions for it. unfortunatelly if you are on Windows best option is to use Mono-D for writing code, and VisualD to debug it. (there is also DCD/DScanner but i never tried it myself). also on OS X debugging is almost impossible due to some problems with symbols/LTS with DMD =2.065 so far.
Re: foreach over string
On Saturday, 24 May 2014 at 16:46:42 UTC, Kagamin wrote: foreach over string apparently iterates over chars by default instead of dchars. Didn't it prefer dchars? string s=weiß; int i; foreach(c;s)i++; assert(i==5); Nope. if you use foreach(dchar c; s) you will get the iteration by code-point you are looking for.
Network programming
I'm finally making my first concerted foray into D programming. Being a networking guy (and a good history in C and C++) I'm starting with some network code (and trying to use vibe.d as well). However, I'm running into some holes that I'm not sure if I'm overlooking something or just that nobody has run into these themselves yet. As a quick overview, I'm looking to talk to the netlink and tun interfaces on linux, as well as raw IP packets (below UDP and TCP). First up is the D equivalent to htons/ntohs. I've found core.bitop.bswap, but that only works on 32-bit values, and not 16. And come to think of it, it would be blindly swapping the bytes. What about platforms (hello, sparc) where host byte order is the same as network byte order?
Re: Creating ranges over mutable, const, or immutable data structures.
On Saturday, 24 May 2014 at 18:01:43 UTC, Ali Çehreli wrote: On 05/24/2014 10:02 AM, w0rp wrote: I have been writing my own hashmap which can provide forward ranges usable in @safe pure nothrow functions, because it's going to be useful for creating graph data structures with the same. I came to writing my ranges and I figured out how to do everything right for just mutable hashmaps, but I have no idea how to manage the tail-const nature of ranges in a variety of combinations. I figured out that I need to satisfy the following constraints. Create a mutable KeyRange over a map which forwards on the right constness for the key type, so the following must be true. HashMap!(K, V).keys.front - K const(HashMap!(K, V)).keys.front - const(K) immutable(HashMap!(K, V)).keys.front - immutable(K) I have encounted some difficulty in trying to write a range which does this. How timely! :) Jonathan Crapuchettes talked about facing the same issue in his talk at DConf. Perhaps he will post his WrapMutability template here or you can wait for his talk on YouTube. Ali I thought someone would say something like that! I'll wait for the talk I suppose.
Re: foreach over string
On Saturday, 24 May 2014 at 18:18:37 UTC, John Colvin wrote: if you use foreach(dchar c; s) you will get the iteration by code-point you are looking for. Actually I was trying to prevent decoding :) It just occurred to me it can be tricky in generic code.
Re: How to handle try-catch blocks, nothrow and logfiles
On Saturday, 24 May 2014 at 17:55:07 UTC, Ali Çehreli wrote: On 05/24/2014 10:09 AM, Tim wrote: I'm working on an application where I want log all exceptions but I'm not sure what's the best way to realize that. A common solution is to log it in the exception class'es constructor. We even dump the backtrace with libunwind in our C++ application. But this only works for my own exceptions, right? I don't see any way to log exceptions in the constructor for phobos-function which are also able to throw exceptions. However, you may quickly realize that not every thrown exception is log-worthy. The reason is, e.g. a MyMissingFile exception may not be important when there is a default action to follow. No need to log in that case. That's right. It's not necessary to log all exceptions but using a global exception handler wouldn't prevent me from handling such exception in my method so that no exception is generated. It would be nice to have something like Exception, Warning and Info to determine if it's necessary to log it.
Re: Network programming
On 2014-05-24, 11:18 AM, Andre Kostur wrote: I'm finally making my first concerted foray into D programming. Being a networking guy (and a good history in C and C++) I'm starting with some network code (and trying to use vibe.d as well). However, I'm running into some holes that I'm not sure if I'm overlooking something or just that nobody has run into these themselves yet. As a quick overview, I'm looking to talk to the netlink and tun interfaces on linux, as well as raw IP packets (below UDP and TCP). First up is the D equivalent to htons/ntohs. I've found core.bitop.bswap, but that only works on 32-bit values, and not 16. And come to think of it, it would be blindly swapping the bytes. What about platforms (hello, sparc) where host byte order is the same as network byte order? Of course in fine tradition... minutes after posting one finds an answer. I'm looking too low... std.bitmanip has what I'm looking for.
Re: Programming a Game in D? :D
On Saturday, 24 May 2014 at 09:49:30 UTC, evilrat wrote: On Saturday, 24 May 2014 at 09:35:01 UTC, David wrote: On Friday, 23 May 2014 at 17:47:56 UTC, evilrat wrote: why not just use Xamarin Studio with Mono-D? But only the trial of Xamarin Studio is for free, and I used eclipse for Java before and really like it :P actually not. you don't even need to register at all. just go to http://monodevelop.com and get ur XS without all this fancy mobile stuff. So I installed that Xamarin studio (hope i had to), what to do with the mono D thing now? don't know hot to install it :P
Re: How to handle try-catch blocks, nothrow and logfiles
On Saturday, 24 May 2014 at 17:09:24 UTC, Tim wrote: Imagine I've an application where I want log all thrown exceptions. Arguably, that's not something you'd want to do. In a normal application, exceptions get thrown around, and it is completely normal. In particular, the *thrower* has no way to know its context, and whether or not the situation it has encountered is catastrophic exception or completely normal. Only the catcher can know. 2) When I want create an application where all methods are defined as nothrow - how can I realize that? Writing to a log-file is already throwable. Yes, I can catch the exception and write the same to the command line but that's also unsafe... are there any nothrow-function to write a file or something to the command line? It's a bit sad when I want log an exception and I'm unable to write the log entry because something happened. So how can make sure that I log all exceptions? Is that even possible? Well, you seem to be mixing the notion of nothrow and safe, which are orthogonal concepts. Most logging frameworks gag their exceptions, which makes them nothrow. This doesn't mean that exceptional things can't happen: It only means the exceptions will not escape from the call.
Re: How to handle try-catch blocks, nothrow and logfiles
On Saturday, 24 May 2014 at 17:09:24 UTC, Tim wrote:
But doing this in all my methods
You shouldn't do it in all methods, only top-level ones, because
they are called from 3rd party code, which will do whatever
things with the exceptions from nothing to terminating the
application. Already mentioned defensive trick is to log
exception in its constructor, so that there's no way to mute it.
If you log exceptions in all methods, the log quickly becomes
messy.
void handleExceptions(Exception e)
{
// Write to log file
}
void myMethod() throwTo(handleExceptions)
{
// Call something that probably throws an exception
}
If you need only Exception as a parameter for logger, leave it
that way, what do you want to change in that interface?
[Issue 12779] [REG2.066a] -inline makes wrong code under some conditions
https://issues.dlang.org/show_bug.cgi?id=12779 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Kenji Hara k.hara...@gmail.com --- If you use the lib.lib binary, you should emit same version definitions to compile the `main.d`. Otherwise, the class instance size of Foo will be different in each compilation units (lib.d and main.d), then the inlined code will access invalid memory in runtime. In other words, this is expected result. Your compilation steps are just wrong, so the generated execution binary will cause invalid result. --
[Issue 12779] [REG2.066a] -inline makes wrong code under some conditions
https://issues.dlang.org/show_bug.cgi?id=12779 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Hardware|x86_64 |All OS|Windows |All --- Comment #3 from Kenji Hara k.hara...@gmail.com --- Note that, this is unavoidable issue of the languages which supports separate compilation for old simple linkers. If each compilation units is compiled under different conditions, the consistency of the binaries won't be guaranteed. To do it, we should have smart linker that checks the compilation consistency, and add enough meta information into the object files to check it. --
[Issue 12779] [REG2.066a] -inline makes wrong code under some conditions
https://issues.dlang.org/show_bug.cgi?id=12779 --- Comment #4 from j...@red.email.ne.jp --- I see... thank you. I'll change my mind. --
[Issue 12778] Aliasing opBinaryRight to opBinary works only in certain cases
https://issues.dlang.org/show_bug.cgi?id=12778 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3578 (In reply to Andrej Mitrovic from comment #0) I don't know if supporting this kind of aliasing was a feature by design or by mistake. It's definitely nice to have it, but it fails in 'test2'. It should either be fully supported (rejects-valid) or fully rejected (accepts-invalid). If both x.opBinary(y) and y.opBinaryRight(x) found, and they are exactly same symbol, x.opBinary(y) should be preferred. This is consistent with current opEquals behavior - if both x.opEquals(y) and y.opEquals(x) found and they call exactly same symbol, it will be resolved to x.opEquals(y). --
[Issue 7469] template mangling depends on instantiation order
https://issues.dlang.org/show_bug.cgi?id=7469 --- Comment #9 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c9120823c6740dc8141ac153f4da56600b147d73 [Refactoring] Remove comment-out code for the fixed issue 7469 --
[Issue 1528] [tdpl] overloading template and non-template functions
https://issues.dlang.org/show_bug.cgi?id=1528 --- Comment #40 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/33d25844140a0b7785a480cf77f603b40154e7ff [Refactoring] Remove unnecessary workaround for issue 1528 --
[Issue 12794] ddoc does not properly support code snippets for documented parameters
https://issues.dlang.org/show_bug.cgi?id=12794 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com --- In other words the vertical positioning is wrong. --
[Issue 12794] New: ddoc does not properly support code snippets for documented parameters
https://issues.dlang.org/show_bug.cgi?id=12794
Issue ID: 12794
Summary: ddoc does not properly support code snippets for
documented parameters
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ddoc
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
The ddoc output of this function looks bad:
-
foo.
Params:
name = name
callback = A callback. Example of the callback:
-
void someCallback();
{
int x;
}
-
etc = etc
*/
void foo(string name, void function() callback, int etc);
-
The location of the void function() callback parameter is stuck at the left
of the code snippet instead of the beginning of the description which was: A
callback. Example of the callback:
--
[Issue 10819] Implicit conversion error assigning one SortedRange to another when a function literal has been used
https://issues.dlang.org/show_bug.cgi?id=10819
Stewart Gordon s...@iname.com changed:
What|Removed |Added
Keywords||rejects-valid
CC||s...@iname.com
Summary|Invalid comparison for |Implicit conversion error
|equality of lambda |assigning one SortedRange
|functions |to another when a function
||literal has been used
--- Comment #10 from Stewart Gordon s...@iname.com ---
You completely forgot to post the compiler output. Here's what I get (DMD
2.065 Win32):
bz10189.d(8): Error: cannot implicitly convert expression (c) of type
SortedRange!(int[], (a, b) = a b) to SortedRange!(int[], (a, b) = a b)
But the two types are the same.
The same occurs when a D1-style function literal is used
- bz10189a.d -
void main() {
import std.range;
SortedRange!(int[], a b) a;
SortedRange!(int[], a b) b;
b = a;
SortedRange!(int[], function bool(a, b) { return a b; }) c;
SortedRange!(int[], function bool(a, b) { return a b; }) d;
d = c;
}
--
C:\Users\Stewart\Documents\Programming\D\Tests\bugsdmd bz10189a.d
bz10189a.d(8): Error: cannot implicitly convert expression (c) of type
SortedRange!(int[], function bool(a, b)
{
return a b;
}
) to SortedRange!(int[], function bool(a, b)
{
return a b;
}
)
--
--
[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow
https://issues.dlang.org/show_bug.cgi?id=10810 Stewart Gordon s...@iname.com changed: What|Removed |Added Keywords||rejects-valid CC||s...@iname.com --
[Issue 10745] Incomplete and misleading error message: opOpAssign isn't a template
https://issues.dlang.org/show_bug.cgi?id=10745 Stewart Gordon s...@iname.com changed: What|Removed |Added Keywords||diagnostic CC||s...@iname.com --
[Issue 12795] New: atomicLoad allows unsafe removal of shared from class references
https://issues.dlang.org/show_bug.cgi?id=12795
Issue ID: 12795
Summary: atomicLoad allows unsafe removal of shared from class
references
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: kirsy...@gmail.com
Tested with dmd v2.066-devel-ca213d2
---
struct Struct {
int x;
}
class Class {
int x;
}
void main() {
import core.atomic;
shared(Struct*) si = new shared Struct;
shared(Struct)* i = atomicLoad(si); // Safe as expected
shared(Class) sd = new shared(Class)();
Class d = atomicLoad(sd); // Unsafe!
}
---
To find out what went wrong, I copied the definition of atomicLoad and modified
it as such:
---
template HeadUnshared(T) {
static if( is( T U : shared(U*) ) )
alias shared(U)* HeadUnshared;
else
alias T HeadUnshared;
}
HeadUnshared!(T) atomicLoad(T)( ref const shared T val ) nothrow {
pragma(msg, typeof(val) == ~ typeof(val).stringof);
pragma(msg, T == ~ T.stringof);
pragma(msg, typeof(return) == ~ typeof(return).stringof);
return typeof(return).init;
}
---
And the output is:
typeof(val) == shared(const(Struct*))
T == shared(Struct)*
typeof(return) == shared(Struct)*
typeof(val) == shared(const(Class))
T == Class
typeof(return) == Class
--
[Issue 12796] New: std.string toLower array conversion.
https://issues.dlang.org/show_bug.cgi?id=12796 Issue ID: 12796 Summary: std.string toLower array conversion. Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: damian...@hotmail.co.uk import std.string; char[64] w1; w1 = w1.toLower; std\uni.d(6954): Error: e2ir: cannot cast result of type char[] to type char[64] --
[Issue 12796] std.string toLower/toUpper array conversion.
https://issues.dlang.org/show_bug.cgi?id=12796 Damian damian...@hotmail.co.uk changed: What|Removed |Added Summary|std.string toLower array|std.string toLower/toUpper |conversion. |array conversion. --
[Issue 12789] Add -transition=nan to emit floating-point variables default-initialized to NaN
https://issues.dlang.org/show_bug.cgi?id=12789 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |WONTFIX --- Comment #6 from Walter Bright bugzi...@digitalmars.com --- As mentioned in the pull request, issues like these are properly in the domain of a lint-like utility, not the compiler. --
[Issue 12796] std.string toLower/toUpper array conversion.
https://issues.dlang.org/show_bug.cgi?id=12796 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #1 from monarchdo...@gmail.com --- FYI, the ice issue is 12769 and fixed. https://issues.dlang.org/show_bug.cgi?id=12769 HEAD currently produces: std/uni.d(8042): Error: template std.array.appender cannot deduce function from argument types !(char[64])(char[]), candidates are: std/array.d(2707):std.array.appender(A : E[], E)() std/array.d(2712):std.array.appender(A : E[], E)(A array) std/array.d(3025):std.array.appender(A : E[]*, E)(A array) std/uni.d(8377): Error: template instance std.uni.toCase!(toLowerIndex, 1043, toLowerTab, char[64]) error instantiating main.d(11):instantiated from here: toLower!(char[64]) --
