Re: TickDuration deprecation
On 2017-11-23 12:55, sarn wrote: +1 to using integer arithmetic for the low-level time APIs. and nobody is advocating to change this. it is about being able to use such result (duration) with non-time focused libraries/functions (eg. general maths/stats) expecting doubles. if this is not possible in an obvious/standard way (being to!... in D) this is the very moment all potential python-to-D converts will run away screaming. putting the solution for this common problem only in the docs will not appease them either but rather make them mock D. i still don't understand how problems could arise from a supported one-way conversion -> double. of course, double -> time or duration is something different and i tend to agree that this should be left for the user to implement. i for my part could live with just one supported to!double conversion resulting in seconds. (i guess i am biased as i prefer to use SI units only for all my calculations.) /det
Re: Multiline string literal improvements
string a = |q{
firstLine();
if (cond) {
secondLine()
}
};
you could write your own string processing function according to your
needs to filter the code string, and use it like
string a = inject(q{...}) //or
string a = inject!(formatOpts)(q{...})
i have done this myself and also included positional argument formatting
to my liking, optimized for CT code generation. don't have the code at
my hands ATM though. could post it later if you are interested.
/det
Re: GTKD resources
On 2017-08-11 13:00, Mr. Pib wrote:
How can one include external files such as glade, icons, images that are
static in nature in to the binary but not require extraction on program
run to be used?
gtk's builder doesn't seem to take an in memory representation of glade
files and building a pixbuf seems quite over the top to do such simple
things?
including the glade UI/XML defs to the executable is simple, compile
with -J. switch and:
immutable string UIdefs = import("myuidefs.glade");
...
main(){
...
builder.addFromString( UIdefs );
...
Re: Who maintains the D website?
i see you didn't hold your horses... not sure if i should reply again to such an angry rant. i will stay calm and focused though. It's not! I've used nntp and it crap. You cannot edit your posts, simple as that! so i give you that. unfortunately, your long rant offers no other argument. however, the editing part is not a biggy. don't be ashamed of the little typo. everything else: i see this NG as some sort of public conversation. be nice, and if you got something wrong then heck, that's life, ppl are wrong all the time. own it - or are you that insecure? however, if you travel back in time and edit your post, you potentially break the rest of the conversation and ppl reading the thread later will not understand what the other participants responded to your post. Of course, it won't happen because those in power know the outcome. You can see how nntp is dead. There are few nntp servers and most of the groups are dead and only those that used in in the past still use it. There is not a migration towards nntp but away, and that is fact... nobody would deny this. but change is not necessarily always for the better. i do understand why email clients, news readers and nntp are less popular these days, it is because of the smart phone generation of users. and this is ok for many topics. but when i am programming - and catching up with the NG, i do sit at a desktop computer and not using the power of a standalone email client or news reader, fast and configured exactly to my liking, seems rather stupid. which suggests that it is not as good as its opposition. Hence, if I'm right, and I almost surely am(surely you are not going to argue that nntp is becoming more popular, are you?) then those that think that nntp is a great thing and better than the alternatives have psychological issues with change. this NG also serves as a compendium for the D language. many posts and threads are valuable years after they have been made. as i pointed out above, the ability to arbitrarily edit your old posts and potentially render threads unintelligible is not convincing to me. again: what other "advantage" is there, what features are you missing (from the web interface)? everything but editing can potentially be added to the current web interface. just file a feature request. You can make a forum that behaves similarly(no login), customizable, or whatever else you are saying that you like about nntp. well, you cannot for me. as i generally don't allow (permanent) cookies (only the occasional session cookie), i would have to login every time. also, i have not seen a web forum yet where i can manoeuvre from post to post or topic to topic as fast as with a standalone reader that locally caches posts and threads. the only time i ever use the web interface is when i am searching/investigating an issue beyond the message cache of my reader. I personally have nothing against nntp... while it isn't great it does the job EXCEPT editing. I know people claim that editing posts causes problems but that is rarely the case and the benefits far out weight any negatives. always funny when rhetoric fails so badly - your post made it quite clear that you, personally, are extremely opposed to nntp. that is ok though, we don't have to have the same opinion. but please, remind me, what are all the many great benefits of editing posts? i gave you one big argument against. The reasons not to move forward are the same reasons [...] your exaggerations are quite amusing to read. as i have to believe that you are serious here, i gracefully refrain from commenting. /det -- "just take it easy man." [the dude]
Re: Who maintains the D website?
On 2017-08-04 12:13, Johnson Jones wrote: No, sorry. The lead team uses nttp which is old school forum technology. They won't move in to the present and instead insist everyone else stay in the past with them. It's sort of like those guys that drive 1970's camaro's because they think it makes them look cool. I'm sure it's a psychological condition but not much can be done about it. hold your horses! quite a number of users incl myself prefer nttp. nice as the forum web interface is, following a newsgroup with a newsgroup reader like eg the thunderbird built-in is way more comfortable, you should try it one day. eg: you don't have to sign in, can reply immediately, you can customize display/behaviour more thoroughly to your liking, and more. /det
Re: NG technical issues: Is it just me?
tried the 'check for new messages every 2 minutes' hotfix suggestion (was set to 10), but it does not help in my case. correction: this seems to help quite a bit, got only one connection refused since.
Re: NG technical issues: Is it just me?
When I try to select a new unread message to read, I've got roughly a 10% or so chance that it'll fail with a "The connection was refused when attempting to contact news.digitalmars.com:119." same here, started several weeks ago, very annoying. i have used the same local config/settings for years w/o probs, also, have NOT upgraded thunderbird, so the issue must be on the server side. tried the 'check for new messages every 2 minutes' hotfix suggestion (was set to 10), but it does not help in my case. /det
Re: Fun: Shooting yourself in the foot in D
as i just happened to have me mutilated, i couldn't resist (even though
the example 'works' only with DMD-m64 bullets):
being forced to share your foot among parallel universes, it will surely
find a stray bullet in one of them.
can you guess which toe is going to be blown off?
'''
version(DigitalMars)version(D_LP64){
import std.stdio: writeln;
import core.atomic : atomicOp;
ulong toe0 = 2;
shared ulong toe1 = 2;
shared ulong toe2 = 2;
shared ulong toe3 = 2;
uint bullet1 = 1;
int bullet2 = 1;
ulong bullet3 = 1;
toe0 -= 1;
writeln( "toe0: ", toe0 );
atomicOp!"-="( toe1, bullet1 );
writeln( "toe1: ", toe1 );
atomicOp!"-="( toe2, bullet2 );
writeln( "toe2: ", toe2 );
atomicOp!"-="( toe3, bullet3 );
writeln( "toe3: ", toe3 );
}
( https://issues.dlang.org/show_bug.cgi?id=16651 )
Re: is __traits(allMembers) usable in a non-deprecated way?
On Friday, 8 April 2016 at 09:50:52 UTC, Atila Neves wrote:
On Thursday, 7 April 2016 at 05:41:06 UTC, E.S. Quinn wrote:
__traits(allMembers, ) has always been pretty much
essential to any non-trivial struct, class, or module-based
introspection, but given the visibility rules changes in
2.071.0, it looks like it's not even allowed to check whether
a given symbol is public. (i.e. with __traits(getProtection,
Type, member))
Is there a new, approved way of doing this?
I just had to change unit-threaded to get it to compile without
deprecation warnings (and in one case a compiler error). I
don't know of any approved way of doing it, I just did the
first thing that worked, which was to check if something was
private by:
private template isPrivate(alias module_, string moduleMember) {
mixin(`import ` ~ fullyQualifiedName!module_ ~ `: ` ~
moduleMember ~ `;`);
static if(__traits(compiles,
isSomeFunction!(mixin(moduleMember {
enum isPrivate = false;
} else {
enum isPrivate = true;
}
}
Notice the mixed-in import.
Atila
i just tried this trick for the first time. it does not seem to
work for me (Windows/DMD32 D Compiler v2.071.1): it alway returns
false, even for private members. is there another way? (i have
the same problem as OP.
post 2.071 mixin template & import rules
the way import declarations work has changed quite a bit with 2.071. two
aspects have been written up nicely by steve schveighoffer (
http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071 ).
breaking as they might be for some, they are (a) a mere enforcement of
the rules as they were always set out and (b) a change in look-up order
preventing hijacking/overshadowing.
it appears that there had been an even more radical change as well with
respect to the way mixin templates work. this has not been properly
communicated yet. at least i could not find a write-up and a related
thread conveyed rather guesswork than knowledge. (
https://forum.dlang.org/post/nl2bgi$2oim$1...@digitalmars.com )
from this thread i tried to distill the gist below... so that if my
understanding is confirmed by the language devs, it may serve as an
explanation of changes complementary to steve's blog post.
mixin templates - https://dlang.org/spec/template-mixin.html :
"A TemplateMixin takes an arbitrary set of declarations from the body of
a TemplateDeclaration and inserts them into the current context."
as of the the specs https://dlang.org/spec/module.html imports are
declarations too and before 2.071 the mixin template design spec above
would work for them just the same. as in:
```
mixin template AddImp (){
import core.thread;
}
mixin AddImp;
```
this would import core.thread just alright into the current scope.
regardless where the instantiation happens, module level as well as
within classes etc. (note that the mixin template definition can be in
another module and itself be constructed by more mixin templates or
string mixins.)
especially if
```
module a;
mixin template AddImp (){
public import core.thread;
}
```
and
```
module b;
mixin AddImp;
```
ie on module level, then in module b core.thread as a whole would be
visible/accessible/imported.
apparently starting with 2.071 import declarations are not treated as
declarations in the sense of mixin templates anymore. meaning that whole
module imports (private and public) in mixin template definitions are
not inserted into the instantiating scope anymore. neither if
instantiated on module level, nor if in a class etc. it is not that the
look-up order has changed for them, they are blatantly ignored now.
(and this is what i am not happy with it. it would be more consisting if
the imports would be inserted in the current scope just as they were
before but with the local definitions having precedence - similar to how
issue 10378 was fixed - just as it would be if you actually wrote
"import core.thread;" instead of "mixin AddImp;" also, it would not
leave me with a ton of code that needs rewriting.)
on the other hand, if not a whole module is imported but individual
symbols via selective import, it still works the same as before. eg:
```
module a;
mixin template AddImp (){
public import core.thread : Thread;
}
```
and
```
module b;
mixin AddImp;
```
will make Thread available in all of module b.
please correct my view of things if i got it wrong.
thanks
/det
Re: DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from mixin templates are ignored
Author here. I originally thought the issue was that an 'imported' scope imports are not considered anymore. this is exactly what i was/am afraid of ...[see below] As Walter explained in this issue and in https://issues.dlang.org/show_bug.cgi?id=15966 this behaviour changed to prevent hijacking and is intended. 15966 is about "protected" and the very example in 15925 uses a protected import too. not sure about the protected story. the scary thing is that the example in issue 15925 also fails to work if it is a public import inside the mixin template. does this mean mixin templates now have no way of adding imports to the scope they are mixed in? this is really bad news for meta programming. i would have to do this with ugly string mixins from now on, or is this unintended behavior for string mixins as well? or is all this a special case for classes? how about at module level? where is all this mentioned in the specs? this leaves me quite confused.
DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from mixin templates are ignored
the changelog to 2.071.1 lists 15925 as a fixed regression, and https://issues.dlang.org/show_bug.cgi?id=15925 lists it as "RESOLVED FIXED" however, the issue as originally submitted still exists in 2.071.1. so what is going on? for me as a non-core dev it is difficult to get the gist of the discussion on the issue tracker... BUT if it was decided that 15925 is INVALID or WONTFIX it must not be marked as RESOLVED FIXED and be featured as a fixed regression. i thought i understood the enforced import rules. but if 15925 is indeed invalid, it looks like there had been also changes to the way mixin statements (and maybe even mixin expressions?) work. is this explained anywhere? thanks /det
Re: core.stdc.stdlib.malloc & alignment
On 2016-06-29 14:39, Hiemlick Hiemlicker wrote: Yes, the C standard requires malloc to be aligned to the platform size(4 for 32bit, 8 for 64-bit). just what i was hopping for. thanks!
core.stdc.stdlib.malloc & alignment
is there an alignment guarantee for core.stdc.stdlib.malloc? more specifically, using DMD and compiling for 32bit on windows, can i assume proper alignment for int or uint variables? background: i like to re-use a (ubyte) buffer, sometimes it will store only bytes, sometimes it shall store uints. thanks
Re: Using .lib and .dll in D applications
On 2016-06-20 06:33, moe wrote: I see where I went wrong. I thought that it's possible to only use the .lib file without the source code of dbar. Having access to the source makes what I am trying somewhat pointless. Is it otherwise possible to provide some functionality without having to give away your source? I would like to put together a library that I can reuse, without having to rely on the source each time. Maybe a dll instead? for this purpose there are .di interface files that can be generated automatically: https://dlang.org/dmd-windows.html#interface-files
Re: GTKD - overrideBackgroundColor of Button doesn't work
string cssPath = "test.css";
CssProvider provider = new CssProvider();
provider.loadFromPath(cssPath);
unfortunately i don't know anything about yr specific problem.
but i just wanted to mention (in case you are not aware of it) that the
CSS can be embedded into the D source. this is what i did to fix GTKs
terrible design mistake for the background of Notebook:
```
enum myCSS = q{
GtkNotebook {
background-color: #e9e9e9;
}
GtkNotebook tab {
background-color: #d6d6d6;
}
};
...
int main(string[] args){
...
import gtk.CssProvider;
auto styleProvider = new CssProvider;
styleProvider.loadFromData(myCSS);
import gdk.Screen;
import gtk.StyleContext;
StyleContext.addProviderForScreen( Screen.getDefault(),
styleProvider, 800);
```
Re: Anybody still using the chm docs
On 2016-06-16 00:29, rikki cattermole wrote: Honestly? I read the source for Phobos even with a internet connection quite often. So having it not included isn't an issue there, but spec is. real programmers do ... well, i do sometimes too. but i rather regard myself as an average user, while i see you as an advanced developer. ppl like me like easy digestible documentation. i don't want to start a fight here. if it has to go it has to go. just making a point that it is useful for some. maybe a 2nd pdf could be made instead containing the phobos docs?
Re: Anybody still using the chm docs
As long as pdf is still being generated I see no reason to not drop it. Cost vs benefit. not sure what pdf you are referring to. https://dlang.org/dlangspec.pdf ? - this is only the language spec. the chm contains the whole website incl phobos documentation, compiler options, articles and style guide. or is there another pdf hiding somewhere? /det
Re: Anybody still using the chm docs
It's a huge maintenance effort for us to produce the chm files. ... So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release? i am very glad the chm file exists whenever i am not online, e.g. on a plane or train (free wifi is not a given everywhere). finding something in the local html is quite awkward w/o google... if it really takes up too much time i will understand if it has to go too, especially if i a am the minority. just saying: i do use it occasionally, and whenever i do it is a big help. /det
Re: How to share an appender!string?
On 2016-05-20 07:49, Era Scarecrow wrote: Experimented and quickly got what looks like good clean results. Took your code, ripped out what I didn't want and added in what I did. Simple! https://dpaste.dzfl.pl/6952fdf463b66 i am most curious about your solution. why does printAll() has a synchronized block? in case you would call it before thread_joinAll() i.e. before all threads are terminated? then again, why is there a synchronized block necessary in printAll() at all? it is only reading out data, not writing. (i am still learning the subtleties of multithreading.) /det
Re: Anonymous structure
On 2016-04-18 14:12, Tofu Ninja wrote:
Also is there a way to have a named substructure, not a nested structure
but something to just add an additional name, maybe something like
struct a{
struct{
int x;
int y;
int z;
} b;
}
not sure what you mean by "named substructure, not a nested structure"
but this works:
struct Outer{
struct Inner{
int x;
int y;
int z;
}
Inner inner;
int a;
}
Outer outer;
outer.a = 7;
outer.inner.y = 42;
// outer.x = 13; //fails
writeln(outer);
Re: Please vote for the DConf logo
On 2015-11-12 11:18, Nemanja Boric wrote: On Tuesday, 10 November 2015 at 10:01:24 UTC, Shriramana Sharma wrote: I prefer 3. It's simple, but effective. The graphic looks like an Olympic torch to me, which is good, indicating that D is a champion! :-) https://de.wikipedia.org/wiki/Berliner_Fernsehturm :-) https://en.wikipedia.org/wiki/Fernsehturm_Berlin
Re: Please vote for the DConf logo
On 2015-11-04 03:30, Andrei Alexandrescu wrote: Reply to this with 1.1, 1.2, 2, or 3: 3
2music
more BJM related http://www.amazon.com/Declare-Nothing-Parks-Anton-Newcombe/dp/B00WZXX2NC
Re: 2music
sorry, emailer(me) malfunction. pls ignore
Re: GtkD 3.1.0 released, GTK+ with D.
On 2015-03-27 16:47, Mike Wey wrote: On 03/27/2015 10:27 PM, captaindet wrote: On 2015-03-26 17:41, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. Shortly after the last release, GtkD has been updated for GTK+ 3.16. GtkD 3.1.0 is now available on gtkd.org: http://gtkd.org/download.html great news - thanks for your efforts! there is a name conflict though. folder \srcgstreamer\gstreamer\ contains GStreamer.d and gstreamer.d this is not supported on windows machines i don't think DMD supports differentiating between them either. /det Fixed in 3.1.1. thanks a bunch! i ran into something else concerning Builder.addFromString in the 1.x versions it was uint addFromString(string buffer, gsize length) (clumsy C style) in the 2.x versions it became uint addFromString(string buffer) (D-ified, made sense) with 3.x it reverted to uint addFromString(string buffer, size_t length) (back to clumsy C style) i don't really like to change my code again and make it incompatible with 2.x versions. and i don't like the clumsy C style either. i'd appreciate if you could add an overload for the D style 2.x version call. cheers, det
Re: GtkD 3.1.0 released, GTK+ with D.
On 2015-03-26 17:41, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. Shortly after the last release, GtkD has been updated for GTK+ 3.16. GtkD 3.1.0 is now available on gtkd.org: http://gtkd.org/download.html great news - thanks for your efforts! there is a name conflict though. folder \srcgstreamer\gstreamer\ contains GStreamer.d and gstreamer.d this is not supported on windows machines i don't think DMD supports differentiating between them either. /det
Re: GtkD 3.0-beta
On 2015-03-10 18:05, jollie wrote: On Tue, 10 Mar 2015 15:41:54 -0500, captaindet wrote: thanks a lot, jollie, for the detailed description. i tried as advised, the shell output was a bit different than in your example, i guess because i installed the 32 bit version and your example was probably for 64bit. I have been using both 32 and 64 bit msys2. For this example, I was using i686(32bit). If your machine is a 32bit machine use i686 or x86_64 for a 64bit machine. Once msys2 is installed, you can download 32bit or 64bit mingw_w64 packages. In this example C:\msys32\mingw32 one question regarding 32 vs 64 bit MSYS2: i am on 64bit win7, but for the time being i only use the dmd toolchain, i.e., i create 32bit executables using optlink. so i need the 32bit GTK3 to call into. quite confusingly MSYS2 i686 (32bit) created a mingw32 and a mingw64 folder. so i was wondering if i could - or rather should - install MSYS2 x86_64 (64bit) after all and then be able to use the mingw32 folder for my 32bit D applications? would this be possible just by installing the one gtk3 package you mentioned (mingw-w64-i686-gtk3)? the problem though is that my GTK application lost most icons and there are tons of warning/critical messages (repeating every time i move the mouse): Most likely, the adwaita theme was not installed. Try to download the icon themes again. This will say [installed] if theme is installed. Here I have both 32/64 bit. $ pacman -Ss adwaita mingw32/mingw-w64-i686-adwaita-icon-theme 3.15.1-1 (mingw-w64-i686-gnome) [installed] GNOME icon theme (mingw-w64) mingw64/mingw-w64-x86_64-adwaita-icon-theme 3.15.1-1 (mingw-w64-x86_64-gnome) [installed] GNOME icon theme (mingw-w64) If not type: $ pacman -S mingw-w64-i686-adwaita-icon-theme mingw-w64-i686-hicolor-icon-theme it works now! i figured that the original installation was incomplete because i had to set rules for a lot of program executions and internet accesses (firewall rules). some parts of the MSYS2 install script timed out too quick and therefor some packages were skipped. i just followed the instructions on http://sourceforge.net/p/msys2/wiki/MSYS2%20installation part III. updating packages - and everything is there now (icons, pixbuffer dependencies). so far it works better than 3.8 which produced a good deal of these CRITICAL messages... also it is so much prettier ;) thanks jollie for your help getting GTK3 via MSYS2 and mike for providing GtkD!! /det ps: the mingw32 folder is 150MB (bin, etc, share only), the GTK3.8 folder was only ~50MB. gotta play with it a bit to see what i can leave out before distributing to other machines..
Re: GtkD 3.0-beta
On 2015-03-08 22:23, jollie wrote: captaindet2k...@gmx.net Wrote in message: can you point me to a DL of 3.14 for windows? I have been using msys2. The mingw-w64 ports work well and include an x86 and x86_64 version. jollie and it also allows using the latest version of glade! /det
Re: GtkD 3.0-beta
On 2015-03-10 10:56, jollie wrote:
On Mon, 09 Mar 2015 13:48:54 -0500, captaindet wrote:
thanks for the info. however, i am not familiar with this project. to be
honest, it is not quite clear to me what MSYS2 is good for or who would need
it. the dox are very slim. so before i dig too deep into what looks like a lot
of trouble/work, may i ask you this:
after original package installation setup whatnot, will i end up with a
dedicated gtk3 folder somewhere that acts as a (self-sufficient) runtime environment -
i.e., will i be able to just zip this folder, distribute it to colleagues, unzip it and set
the windows path to include the gtk/bin and then gkt 3.14+ can be used on this computer?
if not, MSYS2 would be of no use to me.
/det
http://sourceforge.net/projects/msys2/
click Files tab you will see Base and REPOS.
click Base and you will see X86_64 and i686.
which version of msys2 do you want/need?
if you need 64bit select x86_64
else
if you need 32bit select i686
There is an installer you can use, I opt to use
the tar.xz file and unpack it in the root dir
to avoid spaces in dir/filenames.
Run the Drive:\{msys32,msys64}\msys2_shell.bat file.
It will initialize some things then you close window
when done.
Run the Drive:\{msys32,msys64}\msys2_shell.bat file
again use pacman package manager to install packages.
type the following pacman command to download gtk3
and its dependencies.
$ pacman -S mingw-w64-i686-gtk3
resolving dependencies...
looking for conflicting packages...
warning: dependency cycle detected:
warning: mingw-w64-i686-harfbuzz will be installed before its
mingw-w64-i686-freetype dependency
warning: dependency cycle detected:
warning: mingw-w64-i686-cairo will be installed before its
mingw-w64-i686-freetype dependency
warning: dependency cycle detected:
warning: mingw-w64-i686-fontconfig will be installed before its
mingw-w64-i686-freetype dependency
Packages (42) db-5.3.28-2 gdbm-1.11-3 libdb-5.3.28-2 libgdbm-1.11-3
mingw-w64-i686-adwaita-icon-theme-3.15.1-1
mingw-w64-i686-atk-2.15.4-1 mingw-w64-i686-bzip2-1.0.6-3
mingw-w64-i686-cairo-1.14.0-3 mingw-w64-i686-expat-2.1.0-4
mingw-w64-i686-fontconfig-2.11.1-3
mingw-w64-i686-freetype-2.5.5-3 mingw-w64-i686-gcc-libs-4.9.2-4
mingw-w64-i686-gdk-pixbuf2-2.31.1-2
mingw-w64-i686-gettext-0.19.4-2 mingw-w64-i686-glib2-2.42.2-2
mingw-w64-i686-gmp-6.0.0-2 mingw-w64-i686-gnome-common-3.14.0-1
mingw-w64-i686-harfbuzz-0.9.39-1
mingw-w64-i686-hicolor-icon-theme-0.14-1
mingw-w64-i686-icon-naming-utils-0.8.90-1
mingw-w64-i686-jasper-1.900.1-3 mingw-w64-i686-jbigkit-2.1-1
mingw-w64-i686-json-glib-1.0.2-2 mingw-w64-i686-libcroco-0.6.8-2
mingw-w64-i686-libffi-3.2.1-2 mingw-w64-i686-libiconv-1.14-3
mingw-w64-i686-libjpeg-turbo-1.4.0-2
mingw-w64-i686-libpng-1.6.16-1 mingw-w64-i686-librsvg-2.40.6-1
mingw-w64-i686-libtiff-4.0.3-4
mingw-w64-i686-libwinpthread-git-5.0.0.4455.32db221-1
mingw-w64-i686-libxml2-2.9.2-5 mingw-w64-i686-lzo2-2.09-1
mingw-w64-i686-pango-1.36.8-2 mingw-w64-i686-pixman-0.32.6-2
mingw-w64-i686-shared-mime-info-1.4-1 mingw-w64-i686-xz-5.2.1-1
mingw-w64-i686-zlib-1.2.8-6 perl-5.20.2-1
perl-XML-Parser-2.43-1 perl-XML-Simple-2.20-2
mingw-w64-i686-gtk3-3.14.9-2
Total Installed Size: 229.98 MiB
:: Proceed with installation? [Y/n]
Type Y and pacman will download and install gtk3
in the Drive:\{msys32,msys64}\{mingw32,mingw64}
folder.
Pack the appropriate mingw{32,64} folder and you
have a gtk3 runtime. (this will include c library
and include files, I will leave it to you to
separate the wheat from the chaff).
Alternatively, I just set my path to include
Drive:\{msys32,msys64}\{mingw32,mingw64}\bin,
then use pacman to update my files.
thanks a lot, jollie, for the detailed description. i tried as advised, the
shell output was a bit different than in your example, i guess because i
installed the 32 bit version and your example was probably for 64bit.
the problem though is that my GTK application lost most icons and there are
tons of warning/critical messages (repeating every time i move the mouse):
Gtk-WARNING **: Error loading theme icon 'help-contents' for stock: Icon
'help-contents' not present in theme
Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon
'image-missing' not present in theme
GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Gdk-CRITICAL **: gdk_cairo_surface_create_from_pixbuf: assertion 'GDK_IS_PIXBUF
(pixbuf)' failed
GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)'
failed
any idea how to fix this?
cheers,
det
Re: GtkD 3.0-beta
On 2015-03-08 22:23, jollie wrote: captaindet2k...@gmx.net Wrote in message: can you point me to a DL of 3.14 for windows? I have been using msys2. The mingw-w64 ports work well and include an x86 and x86_64 version. jollie thanks for the info. however, i am not familiar with this project. to be honest, it is not quite clear to me what MSYS2 is good for or who would need it. the dox are very slim. so before i dig too deep into what looks like a lot of trouble/work, may i ask you this: after original package installation setup whatnot, will i end up with a dedicated gtk3 folder somewhere that acts as a (self-sufficient) runtime environment - i.e., will i be able to just zip this folder, distribute it to colleagues, unzip it and set the windows path to include the gtk/bin and then gkt 3.14+ can be used on this computer? if not, MSYS2 would be of no use to me. /det
Re: GtkD 3.0-beta
On 2015-03-07 15:14, Mike Wey wrote: I'm glad to announce the first GtkD release that makes use of the new gir based generator. The generator was rebuild from the ground up since the old one was no longer usable with the new GTK+ documentation. For a list of changes see the changelog: http://gtkd.org/changelog.html There is also an list of the breaking changes on the wiki: https://github.com/gtkd-developers/GtkD/wiki/GtkD-2-vs-GtkD-3 Download: http://gtkd.org/Downloads/sources/GtkD-3.0.0-beta.zip thanks mike, i am looking forward to trying it out soon Wraps the GTK+ 3.14 API what does it mean for windows users? will it work with the 3.8 DL? can you point me to a DL of 3.14 for windows? cheers /det
Re: static void arrays under garbage control?
On 2015-02-26 10:07, Steven Schveighoffer wrote:
Static data I believe is always scanned conservatively because no
type information is stored for it ever, even on allocation (i.e.
program startup).
ouh, the confusion goes on... are you saying that
{
// will be all scanned by GC for
// potential pointers into GC managed memory:
void[16] buffer0 = void;
ubyte[16] buffer1;
uint[4] buffer3;
// will not be scanned by GC for pointers:
void[] buffer4 = cast(void[])(new ubyte[16]);
uint[] buffer5 = cast(uint[])(new ubyte[16]);
}
Re: static void arrays under garbage control?
On 2015-02-26 12:07, Steven Schveighoffer wrote:
On 2/26/15 11:57 AM, captaindet wrote:
On 2015-02-26 10:07, Steven Schveighoffer wrote:
Static data I believe is always scanned conservatively because no
type information is stored for it ever, even on allocation (i.e.
program startup).
ouh, the confusion goes on... are you saying that
{
// will be all scanned by GC for
// potential pointers into GC managed memory:
void[16] buffer0 = void;
ubyte[16] buffer1;
uint[4] buffer3;
Yes, all 3 are stack based. This is not static data, which would be like
uint[4] at module level. Those are also treated as scannable, as the entire
stack of every thread is scanned.
// will not be scanned by GC for pointers:
void[] buffer4 = cast(void[])(new ubyte[16]);
uint[] buffer5 = cast(uint[])(new ubyte[16]);
Correct, since they are allocated as ubyte[]. uint[] also would not be scanned.
-Steve
got it, finally! thanks to everyone for their help.
/det
Re: static void arrays under garbage control?
On 2015-02-25 20:45, H. S. Teoh via Digitalmars-d-learn wrote:
On Wed, Feb 25, 2015 at 08:20:37PM -0600, captaindet via Digitalmars-d-learn
wrote:
[...]
struct Stuff2Do{
static ubyte[1024*1024] buffer4speed = void; // even if untyped at this
point
// more
}
[...]
Tangential note: be careful with putting a large static array inside a
struct. Structs are passed by value, which means that if you didn't
allocate that struct on the heap and you pass it around to various
functions, you will overflow your stack very quickly -- every function
call that passes the struct will consume 1MB of stack space. Many OSes
do not allocate that much space for the runtime stack.
T
this is why i tried to get away with a 'static' static array, which only exists once for all Stuff2Do structs. but as it seems, i'll rather need on the order of 512MB buffer, so i will probably go with c.stdlib.malloc
/det
Re: static void arrays under garbage control?
On 2015-02-25 19:24, Adam D. Ruppe wrote:
does this warning only apply to dynamic void[] arrays but not to static
void[CTconstant] arrays?
Both of those will be scanned for pointers.
thanks, adam,
so i should always use
struct Stuff2Do{
static ubyte[1024*1024] buffer4speed = void; // even if untyped at this
point
// more
}
to avoid that the GC is scanning my buffer for pointers?
static void arrays under garbage control?
if i understand correctly, static arrays are exempt from GC scanning for memory pointers http://dlang.org/garbage.html : Pointers in D can be broadly divided into two categories: Those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by calls to C's malloc(), pointers received from C library routines, pointers to static data. but there is also a warning for void arrays http://dlang.org/arrays.html : The garbage collector will scan void[] arrays for pointers, since such an array may have been implicitly converted from an array of pointers or an array of elements that contain pointers. does this warning only apply to dynamic void[] arrays but not to static void[CTconstant] arrays? (because sometimes the docs also mean static arrays even if just type[] is written.) thanks! ps: this is for 32bit apps
Re: H1 2015 Priorities and Bare-Metal Programming
On 2015-02-03 05:05, Daniel Murphy wrote:
Walter Bright wrote in message news:maq8ao$2idu$1...@digitalmars.com...
Yup. I understand the concern that a compiler would opt out of
inlining those if it legally could, but I just cannot see that
happening in reality. Modern compilers have been inlining for 25
years now, and they're not likely to just stop doing it.
No, the problem is that the code might accidentally contain a
construct that is not inlineable. The user will expect it to be
inlined, but the compiler will silently fail.
eg
void myWrapperFunc()
{
callSomeFunc(999, 123, something);
}
This function will not be inlined if callSomeFunc has a default
arugment that calls alloca, for example. If a hidden failure becomes
a compiler error, the user can trivially correct the problem.
+1
i am a simple user writing mostly programs to crunch my scientific data. i'd
like to move my C code to D. but i deal with GBs of data that i have to sieve
through many times. in C, i have lots of repeating integer stunts in the inner
loop that must be inlined. i used macros for this. if i cannot mark small
helper function in the inner loop so that they are guaranteed to be inlined, i
am screwed. i would have to copy and paste lots of code, making the result
worse than the C code.
i am fine with a compilation error when force_inclining fails, if it comes with a
brief explanation of why so i get an idea of how to fix it and make it work. i am
not writing or reading assembler and i don't plan to. but i also don't want to be
in doubt about the inlining. i just want to get stuff done in a convenient way. if
D offers no way other than copypasting code blocks i cannot use it for my
work. sadly.
/det
one of the weirdest bugs ever - request for testing
hi,
i just run into a (wrong code gen?) bug that manifests itself only under
certain conditions.
before i file it, i'd like to know if it is still around in the latest DMD
version and/or if other platforms and 64bit code is affected as well.
bug description:
std.algorithm.countUntil fails to find the needle
my system:
DMD 2.0642 compiling into 32bit code on Win7 64bit
required conditions:
compile with -release -inline -noboundscheck
(an additional -O will also cause the bug)
AND the module imports std.file
/det
import std.stdio;
import std.algorithm;
import std.file;// not needed, but if imported, causing trouble, see below
void main()
{
auto names = [one,FOO,two,three];
// wrong code gen(*) with -release -O -inline -noboundscheck or
// with -release -inline -noboundscheck but only if std.file is imported:
auto x = countUntil( names, FOO );
write(x);
if( 0 = x ) writeln( found a FOO); // (*) not found!
}
Re: one of the weirdest bugs ever - request for testing
On 2014-06-12 14:20, captaindet wrote: before i file it, i'd like to know if it is still around in the latest DMD version and/or if other platforms and 64bit code is affected as well. thanks andrew, philippe, i had the suspicion that it is a windows only problem anyway because the only thing that an unused std.file would do is pulling a lot of windows specific stuff (on my system). if now someone could test this with the current DMD on windows, 64 and 32 bit executables... /det
Re: one of the weirdest bugs ever - request for testing
On 2014-06-12 17:27, Rene Zwanenburg wrote: On Thursday, 12 June 2014 at 22:14:23 UTC, captaindet wrote: On 2014-06-12 14:20, captaindet wrote: before i file it, i'd like to know if it is still around in the latest DMD version and/or if other platforms and 64bit code is affected as well. thanks andrew, philippe, i had the suspicion that it is a windows only problem anyway because the only thing that an unused std.file would do is pulling a lot of windows specific stuff (on my system). if now someone could test this with the current DMD on windows, 64 and 32 bit executables... /det No problems with 2.065 on win, both 32 and 64 bit. great, thanks, so no need to file a bug report. some other bugfix seemed to have taken care of the issue alongside. (in the meantime i had the bug confirmed on another win7/64 machine, however, using DMD2.0642 again.) hopefully it is still fixed in 2.066 which will be my next upgrade step once it is out. /det
delegate issue
hi,
i stumbled upon something weird - it looks like a bug to me but maybe it is a
feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
Re: delegate issue
On 2014-06-02 08:08, Marc Schütz schue...@gmx.net wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but
maybe it is a feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a
workaround, but why is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
This doesn't work, because a delegate needs a context it can capture,
which is available only inside of a function.
so the real explanation is that a module as such has no context. much of the
module design has the look and feel as if it were some sort of object, so this
is a bit of a surprise to me. well, i learned something.
thanks,
det
Re: delegate issue
On 2014-06-02 08:03, MrSmith wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but maybe it is a
feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
You can't assign a delegate at compile time now.
But you can do this in static constructor like this:
int delegate(int) dg;
static this()
{
dg = delegate int(int){ return 666; };
}
i knew about the static constructor, mentioned it in my OP ;)
tried it in my project proper and got run-time cycle detected between modules
ctors/dtors :(
something new to figure out now.
thanks, det
Re: delegate issue
On 2014-06-02 08:08, Marc Schütz schue...@gmx.net wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but maybe it is a
feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
This doesn't work, because a delegate needs a context it can capture, which is
available only inside of a function.
The workaround is either, as Mr Smith suggests, to use a static
constructor, or you can use std.functional.toDelegate() (probably,
didn't test).
i knew about the static constructor workaround (mentioned it in my OP). works
in a simple case, but when i tried it in my project proper i hit a run-time
error: cycle detected between modules ctors/dtors :( could be an unrelated, so
far undetected bug, will look into it tonight. will try
std.functional.toDelegate() as well, maybe it will do the trick.
thanks, det
Re: delegate issue
On 2014-06-02 08:08, Marc Schütz schue...@gmx.net wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but
maybe it is a feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
This doesn't work, because a delegate needs a context it can capture,
which is available only inside of a function.
The workaround is either, as Mr Smith suggests, to use a static
constructor, or you can use std.functional.toDelegate() (probably,
didn't test).
FWIW, tried toDelegate() and it does not work either:
module demo2;
import std.functional : toDelegate;
int function(int) fn = function int(int){ return 42; };
// ok
int dg_def(int){ return 666; }
int delegate(int) dg = toDelegate(dg_def);
// c:\D\DMD2\windows\bin\..\..\src\phobos\std\functional.d(758): Error: Cannot
convert int delegate(int a0) @system to void* at compile time
// demo2.d(8):called from here: toDelegate( dg_def)
void main(){}
Re: delegate issue
On 2014-06-02 09:57, Steven Schveighoffer wrote:
On Mon, 02 Jun 2014 10:37:07 -0400, captaindet 2k...@gmx.net wrote:
On 2014-06-02 08:03, MrSmith wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but
maybe it is a feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
You can't assign a delegate at compile time now.
But you can do this in static constructor like this:
int delegate(int) dg;
static this()
{
dg = delegate int(int){ return 666; };
}
i knew about the static constructor, mentioned it in my OP ;)
tried it in my project proper and got run-time cycle detected between modules
ctors/dtors :(
something new to figure out now.
FYI, the module ctor/dtor cycles thing is an interesting problem.
When D decides to call module ctors or dtors, it wants to initialize
them in an order where two initializations don't depend on one
another. For instance:
module a;
import b;
int x;
static this() { x = b.x;}
module b;
import a;
int x;
static this() { x = a.x;}
But of course, D does not know what exactly is done in module a, and
module b. It could be:
module a;
import b;
int x;
static this() { x = b.x; }
module b;
import a;
int x;
static this() { x = 15;}
Which could be perfectly legal, as long as module b is initialized
before module a.
But D doesn't have the information to sort this out. So at the
moment, it has to assume the first situation, and reject the code.
And it can only detect this at runtime, since we have no way to tell
the linker to refuse to link this code.
The typical solution is to put your static ctors into another module,
which nothing will import (and therefore cannot be part of a cycle).
A module with no static ctors/dtors will not be flagged as causing a
problem.
-Steve
thanks a lot, steve! turned out - not surprisingly - that i would run into the
ctor/dtor cycle issue whenever the user code module had a static constructor
(even if not due to the delegate workaround mixin). i was able to refactor my
package and after 'outsourcing' of the static constructor there, i can now use
the mixed in static constructors in the user module to initialize the delegate
with a default. not pretty, but it works!
/det
Re: Suggestion to implement __traits(getImports, Scope)
On 2014-05-09 04:46, Mason McGill wrote: On Friday, 9 May 2014 at 04:09:46 UTC, captaindet wrote: by coincidence, i have use for this too. also thought __traits(allMembers, ...) would work. too bad it doesn't. is this a bug or expected behavior? /det Just out of curiosity, what's your use case? i create a class at compile time to ease interfacing a huge package, mostly to spare the user tons of boilerplate code. not all sub-modules are interesting. since they have to be (public) imported into the module that generates the helping class, this could switch on - in a very transparent way for the user - the generation of respective boilerplate code and exposing functionality. obviously, i want to avoid a public import of the whole package - since only a few sub-modules will be used. currently, i have 2 different places in my helper module where functionality is switched on (for imports, and for code generation) and i don't like it. i will experiment with mixin templates now, but i find this approach ugly and not transparent. /det
Re: Suggestion to implement __traits(getImports, Scope)
On 2014-05-08 13:28, Yuriy wrote: Hello D community, What do you think of a new __traits(getImports, Scope), that returns a tuple of strings, which are imports made in a scope? If scope is a module, it will produce a tuple like (std.conv, std.traits). by coincidence, i have use for this too. also thought __traits(allMembers, ...) would work. too bad it doesn't. is this a bug or expected behavior? /det
Re: Redesign of dlang.org
On 2014-04-18 09:04, Aleksandar Ruzicic wrote: So, what do you guys think? i like it.
for fun, if questionable - a heisenbug
reported as part of issue 12541
https://d.puremagic.com/issues/show_bug.cgi?id=12541
=== CODE ===
module heisenbug;
// pragma(msg, __traits(compiles, test) );
// comment in the pragma and 'enum buggy' below will compile fine
enum buggy = valid!(test);
// Error: variable heisenbug.buggy had semantic errors when compiling
pragma(msg, buggy = ~buggy.stringof);
enum test = 13;
template valid(alias sym){
enum valid = __traits(compiles, sym);
} // no difference if this template is declared first
void main(){}
Re: for fun, if questionable - a heisenbug
On 2014-04-08 15:37, Matej Nanut wrote: On 8 April 2014 22:11, captaindet2k...@gmx.net wrote: [...] I noticed it works if you move the enum declaration above the instantiation of template valid. yes, it requires certain conditions to (dis)appear. those i could figure out are in the bug report ( https://d.puremagic.com/issues/show_bug.cgi?id=12541 ). also, of course, if the _traits method is not templated, it always compiles fine. unfortunately, if you want to apply meta stuff on arbitrary/other ppls code, you don't have the luxury of moving declarations around.
Re: templates, enums, CT reflection: compiler bug or not?
no one any ideas? well, i filed two bug reports for now: https://d.puremagic.com/issues/show_bug.cgi?id=12532 https://d.puremagic.com/issues/show_bug.cgi?id=12533
templates, enums, CT reflection: compiler bug or not?
i stumbled upon something strange while wondering around meta/codegen-lands. it
took me almost a week to reduce it to the following test case. i have no clue
what is going on, whether i have entered bug territory or just encountered my
own limitations
mind you, i have 2 issues with the code:
(1) that my template, which uses __traits(compiles, ...), under certain circumstances (aka 'if things are getting complicated') fails to see symbols that one could argue are valid in this scope. (annoying maybe, but not my main problem)
(2) the strange compiler error i get when using the template on itself, but
only if it is not the first time that the instantiation is used. this is my
real issue cause i don't know how to work around this. during my attempts to
reduce this, starting from much more complicated code, i encountered all sorts
of errors, including ICE and __error stuff.
so am i being stupid or is it a compiler bug?
cheers,
det
===CODE===
module demo;
template valid(string mem){
pragma(msg, instantiation of valid with: ~mem);
static if( !__traits( compiles, mixin(mem) ) ){
enum valid = false;
}else{
enum valid = true;
}
}
enum ok = valid!foo;
pragma(msg, ok ); // - true // fine, recognizes 'foo' in module
scope
enum works = valid!fails;
pragma(msg, works );// - false // problematic, fails to see
'fails' in module scope
enum dummy = valid!fails;
pragma(msg, dummy );// - false // same behavior, as long as you
are not testing yourself
enum fails = valid!fails; // Error: variable demo.fails had semantic
errors when compiling
// NOTE: if you comment out the first two usages of valid!fails, it will work
here,
// although it will result in false
// pragma(msg, fails );
enum foo = 42;
void main(){}
Re: Changing the behavior of the comma operator
On 2014-03-25 12:33, Andrei Alexandrescu wrote: After the recent discussions regarding the comma operator, and after inspecting the patterns of code affected by it, Walter and I would back up the following change to the D language: 1. The comma operator stays with its current syntax. 2. The semantics is the same unless warnings are enabled with -w 3. In -w mode, semantics are changed in that the type of the comma operator is NOT the type of its last expression, but instead it's void. 4. Later on the warning will be promoted to a deprecation followed by removal from the language. mwould this effect comma usage inside for-loops as well or will this be special cased? i would not like to see it go from for-loops. i don't mind otherwise. /det
Re: shouldn't this work? / how to make it work?
On 2014-03-22 19:37, anonymous wrote:
On Saturday, 22 March 2014 at 22:54:15 UTC, captaindet wrote:
pls see example code below.
the two 'test' templates work fine by themselves. if, however, in the same
module, the eponymous template does not work anymore. instead the compiler
seems to try instantiating the variadic template.
a) why? for how i understand it, this should not happen as
o they have very different signatures, i.e. completely incompatible argument lists
( zero vs 1 arguments)
o the string parameter is more specialized than the take-all tuple
b) how can i make it work?
cheers,
det
CODE:
=
import std.stdio;
// cannot be used with function arguments
template test(string str ){
enum test = template 'test' used with ~str;
}
// cannot be called with less than 2 function arguments
string test (T ...)( T strs )
if( 1strs.length )
{
return templated function 'test' called with ~strs[0]~ and ~strs[1];
}
// enum epo = test!one; // use eponymous template
// if commented in:
// Error: tuple T is used as a type
// in line 9 = string test (T ...)( T strs )
enum vari = test(two, three); // use templated/variadic function
void main(string[] args)
{
// writeln( epo );
writeln( vari );
}
Looks like a bug to me.
i thought so too
By the way, the variadic template is eponymous, too: The template
declares a function with the same name.
right
filed a bug report:
https://d.puremagic.com/issues/show_bug.cgi?id=12447
shouldn't this work? / how to make it work?
pls see example code below.
the two 'test' templates work fine by themselves. if, however, in the same
module, the eponymous template does not work anymore. instead the compiler
seems to try instantiating the variadic template.
a) why? for how i understand it, this should not happen as
o they have very different signatures, i.e. completely incompatible argument lists
( zero vs 1 arguments)
o the string parameter is more specialized than the take-all tuple
b) how can i make it work?
cheers,
det
CODE:
=
import std.stdio;
// cannot be used with function arguments
template test(string str ){
enum test = template 'test' used with ~str;
}
// cannot be called with less than 2 function arguments
string test (T ...)( T strs )
if( 1strs.length )
{
return templated function 'test' called with ~strs[0]~ and ~strs[1];
}
// enum epo = test!one; // use eponymous template
// if commented in:
// Error: tuple T is used as a type
// in line 9 = string test (T ...)( T strs )
enum vari = test(two, three); // use templated/variadic function
void main(string[] args)
{
// writeln( epo );
writeln( vari );
}
Re: GladeD - Gtk Glade Files to GtkD classes
On 2014-03-13 11:03, Robert Schadek wrote: Writing gui's by hand is not that much fun. Using glade files is also not so entertaining. GladeD creates class, out of glade files, you can inherited and implement. Glade is just a very small tool, I thought other people might find hand. Check: https://github.com/burner/gladeD very neat! the test worked under windows as well. just a few tweaks were necessary cause i did not want to move yr logger into std, ... yet. i have been working on the same matter recently as well, from quite a different angle though. requires a bit more polishing and testing before i can show it. i am a little bit less motivated now that there is a viable solution to the glade awkwardness ;) /det
Re: Final by default?
On 2014-03-13 22:40, Daniel Murphy wrote:
On the other hand,
class C { virtual: ... }
_does_ trivially bring back virtual-by-default.
is this all it takes? i mean, after switching to final-by-default, going
through anybodies codebase and blindly adding virtual at the very beginning of
each class definition reestablishes to 100% old behavior?
a regex sr can probably do this. or a tiny tool. this is a step everyone can
readily subscribe to. if it is that easy i don't see any grounds for a
too-breaking-change argument.
/det
Re: static foreach (Was: Re: static switch)
On 2014-03-06 16:06, bearophile wrote: Timon Gehr: No. static foreach does not introduce a new scope. TypeTuple-foreach does. Deprecating this language feature is not in scope of the 'static foreach' DIP. It's separate, and I'd even argue for not doing it. My most basic point in this ER is to require a static before foreach when you loop on TypeTuples, because the current situation is confusing for newbies and makes D code less explicit: https://d.puremagic.com/issues/show_bug.cgi?id=4085 Introducing a third type of foreach that is intermediate between the semantucs of the regular foreach and the already present typetuple foreach is ridiculous, will increase the language complexity and will make D and even more confusing for newbies. Bye, bearophile +1
std.algorithm.find and array of needles?
std.algorithm.find has an overload that works with several needles: // phobos doc example: int[] a = [ 1, 4, 2, 3 ]; assert(find(a, [ 1, 3 ], 4) == tuple([ 4, 2, 3 ], 2)); the function i want to write has to deal with variadic arguments serving as needles. unfortunately, i failed trying to make find work with the needles provided in an array: int[] a = [ 9, 8, 7, 6, 5, 4, 3, 2, 1 ]; int[][] ns = [ [ 7, 6 ], [ 4, 3 ] ]; auto res = find( a, ns ); //Error: template std.algorithm.find does not match any function template declaration. Candidates are: any ideas how this can be achieved? thanks /det
Re: std.algorithm.find and array of needles?
On 2014-03-03 14:58, John Colvin wrote:
On Monday, 3 March 2014 at 19:35:53 UTC, captaindet wrote:
std.algorithm.find has an overload that works with several needles:
// phobos doc example:
int[] a = [ 1, 4, 2, 3 ];
assert(find(a, [ 1, 3 ], 4) == tuple([ 4, 2, 3 ], 2));
the function i want to write has to deal with variadic arguments serving as
needles. unfortunately, i failed trying to make find work with the needles
provided in an array:
int[] a = [ 9, 8, 7, 6, 5, 4, 3, 2, 1 ];
int[][] ns = [ [ 7, 6 ], [ 4, 3 ] ];
auto res = find( a, ns );
//Error: template std.algorithm.find does not match any function template
declaration. Candidates are:
any ideas how this can be achieved?
thanks
/det
You can use a variadic template function instead of variadic slice construction:
void foo(A, T ...)(A[] a, T ns)
{
//use find as follows. For example:
return a.find(ns);
}
assert(foo([1,2,3,4], 3, 6, 2) == Tuple!([2,3,4], 2));
thanks, john.
i was afraid that this is the hoop i might have to jump through ;)
which is fine for the simple case i asked for. in another case, i would need to
construct a needle proper from each pre-needle that is one the variadic
arguments. this seems impossible now.
so i probably have to make the pre-needles template parameters and enter the
dreadful realm of std.typetuple... guess staticMap is my friend here.
cheers
/det
Re: std.algorithm.find and array of needles?
On 2014-03-03 16:19, John Colvin wrote:
On Monday, 3 March 2014 at 22:03:24 UTC, captaindet wrote:
On 2014-03-03 14:58, John Colvin wrote:
On Monday, 3 March 2014 at 19:35:53 UTC, captaindet wrote:
std.algorithm.find has an overload that works with several needles:
// phobos doc example:
int[] a = [ 1, 4, 2, 3 ];
assert(find(a, [ 1, 3 ], 4) == tuple([ 4, 2, 3 ], 2));
the function i want to write has to deal with variadic arguments serving as
needles. unfortunately, i failed trying to make find work with the needles
provided in an array:
int[] a = [ 9, 8, 7, 6, 5, 4, 3, 2, 1 ];
int[][] ns = [ [ 7, 6 ], [ 4, 3 ] ];
auto res = find( a, ns );
//Error: template std.algorithm.find does not match any function template
declaration. Candidates are:
any ideas how this can be achieved?
thanks
/det
You can use a variadic template function instead of variadic slice construction:
void foo(A, T ...)(A[] a, T ns)
{
//use find as follows. For example:
return a.find(ns);
}
assert(foo([1,2,3,4], 3, 6, 2) == Tuple!([2,3,4], 2));
thanks, john.
i was afraid that this is the hoop i might have to jump through ;)
which is fine for the simple case i asked for. in another case, i would need to
construct a needle proper from each pre-needle that is one the variadic
arguments. this seems impossible now.
so i probably have to make the pre-needles template parameters and enter the
dreadful realm of std.typetuple... guess staticMap is my friend here.
cheers
/det
Luckily, you don't have to. foreach over tuples is awesome:
import std.typecons;
import std.algorithm;
auto makeProperNeedle(T)(T needle)
{
//do something to needle
return needle;
}
auto foo(A, T ...)(A[] a, T preNeedles)
{
Tuple!T needles;
foreach(i, preNeedle; preNeedles)
{
needles[i] = makeProperNeedle(preNeedle);
}
//use find as follows. For example:
return a.find(needles.expand);
}
unittest
{
assert(foo([1,2,3,4], 3, 6, 2) == tuple([2,3,4], 3));
}
awesome indeed - works like a charm!
many thanks
/det
Re: phobos dependencies
On 2013-12-20 11:38, H. S. Teoh wrote:
On Fri, Dec 20, 2013 at 09:27:55AM -0800, Andrei Alexandrescu wrote:
On 12/20/13 5:45 AM, Joseph Rushton Wakeling wrote:
On 20/12/13 10:06, Meta wrote:
void topN(alias less = a b,
SwapStrategy ss = SwapStrategy.unstable,
Range, RandomGen)(Range r, size_t nth, ref RandomGen rng)
if (isRandomAccessRange!(Range) hasLength!Range
isUniformRNG!RandomGen) //--- needs
std.random.isUniformRNG
{
static assert(ss == SwapStrategy.unstable,
Stable topN not yet implemented);
while (r.length nth)
{
auto pivot = uniform(0, r.length, rng);
// ... etc. ...
}
}
I had this idea fot a while, and Walter is favorable of it as well -
extend import for one-shot use. With that feature the example
would become:
void topN(alias less = a b,
SwapStrategy ss = SwapStrategy.unstable,
Range, RandomGen)(Range r, size_t nth, ref RandomGen rng)
if (isRandomAccessRange!(Range) hasLength!Range
import.std.random.isUniformRNG!RandomGen)
{ ... }
In this case import would syntactically be placed at the beginning
of a qualified name, meaning import this module lazily and look up
the symbol in it.
[...]
Hmm. Why do we need to incorporate the 'import' keyword in the first
place? What about extending symbol lookup, so that if a fully-qualified
symbol x.y.z can't be found in the current symbol tables, and x/y exists
in the current import path, then implicitly try to import x.y and lookup
z in that module. Then you could just write:
void f(T)(T t) if (std.range.isInputRange!T) ...
and the compiler will automatically import std.range within that scope.
Obviously, it's a bad idea to import std.range into module scope, since
it would pollute the module namespace, but it seems a good idea to do a
one-shot import automatically, since the qualified symbol itself already
says which module the symbol is supposed to be defined in. There's no
need to add another import. prefix to it, IMO.
T
one could make it a bit more explicit by requiring
import std;
at module level, or even more explicit
auto import std;
to enable lazy import of everything that is hierarchically below. could then be
used for user libraries as well:
import mybreadandbutter;// has several sub folders /
packages
/det
Re: objects as AA keys
On 2013-10-15 08:32, Daniel Davidson wrote: On Tuesday, 15 October 2013 at 05:44:25 UTC, captaindet wrote: hi, i am a bit confused. the official language ref ( http://dlang.org/hash-map.html ) states: Classes can be used as the KeyType. For this to work, the class definition must override the following member functions of class Object: hash_t toHash() bool opEquals(Object) int opCmp(Object) ... but now i stumbled on http://forum.dlang.org/post/mailman.2445.1354457588.5162.digitalmars-d-le...@puremagic.com int[typeof(O)] rc; rc[O] = 42; auto O2 = O; // [...] if (auto r = O2 in rc) return *r; else return rc[O2] = compute(O2); IOW explicitly taking the address may not be necessary when doing that kind of things. and i did a quick test and indeed, it seems to work out of the box - without overriding any member functions. in my use case, i wouldn't be able to modify the class anyway. so my questions: why is it working, is it just syntactic sugar for using cast(void*)Obj as key? what is the danger of using objects as keys? when would it fail? as it seems to be working against language specs, will this 'feature' eventually be removed? (then maybe i should use cast(void*)Obj right away...) thanks, det Do you have an example where it is really working? The problem of not overriding those functions is that maybe you are not getting what you think. For example, the code below will print: [aaa.S:42] [aaa.S:42, aaa.S:43] This is probably not what you want. If you don't override the functions how is the implementation to know what are equivalent keys? Below you would probably expect two S's that are default constructed to hit the same key spot in the AA. But this does not happen since the implementation does not know you want new S to equal new S because there is no opEquals. Thanks, Dan in my use case i don't have multiple objects with the same state, so keying them per obj_ptr (if this is what is happening) seems to be sufficient for me. (the object classes are 3rd party so i cannot overwrite member functions anyway.) /det
objects as AA keys
hi, i am a bit confused. the official language ref ( http://dlang.org/hash-map.html ) states: Classes can be used as the KeyType. For this to work, the class definition must override the following member functions of class Object: hash_t toHash() bool opEquals(Object) int opCmp(Object) ... but now i stumbled on http://forum.dlang.org/post/mailman.2445.1354457588.5162.digitalmars-d-le...@puremagic.com int[typeof(O)] rc; rc[O] = 42; auto O2 = O; // [...] if (auto r = O2 in rc) return *r; else return rc[O2] = compute(O2); IOW explicitly taking the address may not be necessary when doing that kind of things. and i did a quick test and indeed, it seems to work out of the box - without overriding any member functions. in my use case, i wouldn't be able to modify the class anyway. so my questions: why is it working, is it just syntactic sugar for using cast(void*)Obj as key? what is the danger of using objects as keys? when would it fail? as it seems to be working against language specs, will this 'feature' eventually be removed? (then maybe i should use cast(void*)Obj right away...) thanks, det
Re: compiled code file size
On 2013-09-20 10:03, Duke Normandin wrote: I'm re-visiting the D language. I've compared the file sizes of 2 executables - 1 is compiled C code using gcc; the other is D code using dmd. helloWorld.d = helloWorld.exe = 146,972 bytes ex1hello.c = ex1-hello.exe = 5,661 bytes Why such a huge difference??? Duke maybe somehow related: i have a short program using GtkD. the exe is ~3MB if compiled using dmd and linked to pre-built GtkD.lib (16MB) ~2MB if compiled via bud/build following up on all imports directly, no linking to pre-built lib all compiler flags the same (-debug for exe, prebuilt lib is not debug but -O -inline -release). on windows. /det
Re: [OT] Language Cocktail
On 2013-09-18 11:02, Nick Sabalausky wrote: On Wednesday, 18 September 2013 at 14:35:59 UTC, Namespace wrote: In fairness, there is some really good stuff being brewed in the U.S. Sierra Nevada for example (http://www.sierranevada.com/), and there are some nice micro-breweries that produce quality stuff that is as good as any of the better German, British, Irish or Belgian beers/ales. Or Yuengling. Mainly German-style (although apparently Yuengling does use corn?), by a German immigrant and his descendants, made in Pennsylvania and Florida. Roughly the price of Budweiser Shitty Corn Beer, but actually worth drinking. There's certainly better bier out there, but not at that price point. Can only get it in a few states though, but luckily Ohio here was added a couple years ago :) ouch!! this gives me a phantom acid reflux. Yuengling is hardly german/czech lager/pilsener style but rather appalling. the little flavor it has is mostly metallic/sour. (disclaimer: last time i tried it was in 2005.) yes, i do love my beer. being a german who lived several years in the UK and US (and currently do) i have quite an opinion on this. first thing, i had to give up the idea of finding german style beers (which is mostly pilsener and wheats). buying the stuff imported from germany does not work either, at least not for pilsener, as it is invariably stale and off* (no preservatives!), making my american friends wonder why we like our beer in the first place. so i had to think outside the box, try different styles. and indeed there are many amazing and delicious beers, especially in the US, not so many in the UK though ;) so i am quite happy now drinking IPAs** in the US and pilsener in germany. FWIW, american wheats taste very different from german wheats too, they are citric instead of banana-ry. cannot make my peace with former, but the imported wheats from germany are usually good, not stale. so i am a happy camper overall. as for american beers that resemble fresh/authentic german/czech pilsener most, i can recommend lagunitas pils, victory brewing pils, and to some degree brooklyn lager (sic! their pilsner sucks). but they are not quite there yet. (i suspect none of them takes the main ingredient seriously enough: water - you don't get far starting with US tap water). *quite surprisingly, some folks cannot taste if something is off and don't mind... **sierra nevada is just OK. better IPAs are dogfish head 60 minutes IPA and lagunitas IPA, just to name 2 widely available ones. and of course there are lots of great local microbrew beers as well. cheers, det
Re: [OT] Which IDE / Editor do you use?
mostly geany with bud/build so i don't need any project files but can easily tackle small and medium sized projects. i love the way how bud tracks down all imports, (can) clean up after compilation, and handles different sets of options in option groups - and geany does the rest one of my projects might grow big enough to benefit from a full-fledged IDE, probably MonoD as this project is multi-platform. otherwise VisualD as VS is more stable than monodevelop. i played with both but in general, i find those big IDEs to awkward to deal with for small projects. /det
Re: bug in typeof or wrong enum specs?
On 2013-08-29 12:17, Maxim Fomin wrote: On Thursday, 29 August 2013 at 16:15:50 UTC, captaindet wrote: however, i don't see the issue fully resolved. in enum IDENTIFIER; IDENTIFIER is an identifier, there is no way around it. the enum declaration makes it a type too, but it continues to be an identifier. an identifier is a PrimaryExpression. a PrimaryExpression is an Expression, any expression is officially allowed in typeof. but it throws an error because this expression is a type too. same goes with alias IDENTIFIER2 = int; Grammar rule expression is not necessarily an expression in a general sense of computing values, designating objects or producing side effects. cannot say that this makes it clearer to me. if there is something fuzzy/wrong in the dox or grammar rules then it needs to be fixed. to me, according to the current language specs, an expression can already be (Identifier) or evaluate to a type and typeof(expression) should not throw but return this type. so far i have not seen any convincing explanation why a different behavior is desirable or is making any sense. /det
Re: bug in typeof or wrong enum specs?
thanks dicebot, jacob, rainer. now i understand better what is going on and why. however, i don't see the issue fully resolved. in enum IDENTIFIER; IDENTIFIER is an identifier, there is no way around it. the enum declaration makes it a type too, but it continues to be an identifier. an identifier is a PrimaryExpression. a PrimaryExpression is an Expression, any expression is officially allowed in typeof. but it throws an error because this expression is a type too. same goes with alias IDENTIFIER2 = int; i don't think it can/should be fixed for identifiers only but instead typeof() should cover types in general: typeof(IDENTIFIER) = IDENTIFIER typeof(IDENTIFIER2 ) = int typeof(int) = int i see only advantages in this and it would clean up meta code from handling corner cases. (at least in my case, but being still on the newbie side of D programming i might not do it right.) /det
Re: bug in typeof or wrong enum specs?
On 2013-08-29 14:24, Jacob Carlborg wrote: On 2013-08-29 18:15, captaindet wrote: i see only advantages in this and it would clean up meta code from handling corner cases. (at least in my case, but being still on the newbie side of D programming i might not do it right.) I've already created an enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=10919 thanks! i have just voted for it ;)
Re: [dox] enum specs vs reality
On 2013-08-28 02:21, Jacob Carlborg wrote:
On 2013-08-28 04:27, Andre Artus wrote:
2. The example from p.69 [TDPL]. It seems to be missing a colon
after enum. enum size_t g_maxDataSize = 100_000_000, g_maxMemory
= 1_000_000_000;
I hope someone can clear up what is and isn't a valid enum.
I haven't looked at this in TPL but the above is a manifest constant.
Which basically has nothing to do with enums. It's a way to declare a
constant that doesn't have any storage and which address cannot be
taken. Basically the same as #define foo 0 in C.
don't know what you mean. since they are defined with the enum keyword they
have everything to do with enum, especially the official syntax presented here:
http://dlang.org/enum.html
enum keyword covers both, enumeration constants and manifest constants. the
specs cover both in one. moreover, they explain that manifest constants are
only syntactic sugar for anonymous enums:
enum { A = 2, B = 4 }
is the same as
enum A = 2;
enum B = 4;
Re: [dox] enum specs vs reality
On 2013-08-28 02:26, Jacob Carlborg wrote: That doesn't look entirely correct. Currently the docs read: EnumDeclaration: enum EnumBody Should probably be: EnumDeclaration: enum EnumMembersBody: agreed. The last one will fail since typeof expects an expression and not a type. a) so are you saying enum WhatAmI; is legal? (just asking because i don't know) b) what typeof expects/tolerates seems to be a bit of a minefield by itself. enum test = true; writeln( typeof(test).stringof ); //prints: bool enum wtf; writeln( typeof(wtf).stringof );//Error: argument wtf to typeof is not an expression /det
bug in typeof or wrong enum specs?
a recent discussion ( http://forum.dlang.org/thread/kvje4r$1tff$1...@digitalmars.com ) about the official enum dox ( http://dlang.org/enum.html ) was not conclusive whether enum IDENTIFIER; is officially allowed/supported. jacob pointed out that it has an important use case in that it can serve as UDA. as UDAs are fairly new, this cannot be the reason why this syntax was allowed in the first place though, *if* it is allowed. also, it might be used in meta stuff similar to #define IDENTIFIER in C - playing with this idea i run into this issue... while much code behaves with such an empty enum declaration, writeln( __traits(compiles, IDENTIFIER) ); // true writeln( is( IDENTIFIER == enum ) );// true typeof() is not happy at all (DMD 2.063.2): writeln( typeof(IDENTIFIER).stringof ); // Error: argument IDENTIFIER to typeof is not an expression typeof() expects an expression and a bare identifier is a PrimaryExpression ( http://dlang.org/expression.html#PrimaryExpression ) and hence a valid argument. either the empty enum declaration is not allowed (and should be removed from the dox and throw a compilation error) or there is a bug in typeof(). /det
[dox] enum specs vs reality
i admit that i am not very good at reading/understanding language definition
syntax. but yet i think the given enum specs ( http://dlang.org/enum.html ) are
not quite in order.
they seem to imply that both
enum ;
enum WhatAmI ;
are correct. while the first one throws an error as expected, the second one
passes and is partially usable, potentially similar to C's #define OPTION.
however, typedef's throwing of an error makes me doubt that this is legal:
import std.stdio, std.traits;
enum test; // passes but is it really legal?
int main(string[] args)
{
writeln( __traits(compiles, test) );// true
writeln( is( test == enum ) ); // true
writeln( isBasicType!(test) ); // true
writeln( isSomeFunction!(test) ); // false
// writeln( typeof(test).stringof ); // Error: argument test
to typeof is not an expression
return 0;
}
Re: s/type tuple/template pack/g please
On 2013-08-21 13:36, Meta wrote: On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote: We much more need to get type out of the name. Those aren't types. I think this is part of the problem. Nobody can agree on what they should be called because it's so hard to classify them. They're not types, they're not values, they're this weird in-between thing that can be either one, or the other, or both. Therefore anything containing Type or Value in the name will not describe exactly what this thing is. Neither will Symbol, nor Expression, as it can contain both of those again, but not exclusively. We may as well call it by some name that is completely unrelated to what it can contain, as it can contain pretty much *everything*. How about KitchenSinkquence? abstract tuples they are. (we have to alias them to maintain their full function) i don't mind them being called ...tuples, to me it looks and feels enough like a tuple to be called this way. (Type... is very confusing though). concerning the other typecons.Tuple: i think of this being more an issue of insufficient/bad/confusing documentation. /det
Re: A Discussion of Tuple Syntax
On 2013-08-19 17:04, Meta wrote: On Monday, 19 August 2013 at 21:03:50 UTC, Andrei Alexandrescu wrote: b) syntactic support for ignoring certain members in a destructuring - is that really needed? auto (a, ?, c) = functionReturningTupleOrStaticArrayWith3Elements(); In fairness, it is very common in other languages with pattern matching/destructuring. Off the top of my head I can think of Haskell, ML, Racket, Javascript (destructuring only) and Rust. same in matlab. once destruction-auto assignment is available, (future) library functions will make heavy use of it, e.g. statistics functions returning lots of parameters/characteristics for a dataset. more often than not one is only interested in a few. /det
Re: more enum and pragma troubles
On 2013-08-19 00:31, JS wrote:
module main;
import std.stdio, std.conv;
template foo(alias T)
{
string foo(string s)
{
string x = to!string(T) ~ s ~ ;
//pragma(msg, x); // pragma see's x as a run time variable(or rather pragma is
executed before x is truly defined)
return x;
}
well, i think i understand what is going on in your example. here x is a
runtime value because 's' is passed as a function argument (always runtime
within this very function). template instantiation (this is when pragmas(msg)
is already called) comes first and at this time 's' is unknown, as the
instantiated function could be later called with whatever 's' - the compiler
cannot know what 's' at this point.
tricks i found around this:
a) if current structure of example program is required (i.s. definition of
foo), add a wrapper template for compile time printing:
template _dbg_foo(alias T, string s){
enum x = foo!(T)(s);
pragma(msg, x);
enum _dbg_foo = x;
}
b) if foo does not need to have 's' as an argument, make it a template
parameter, too. you also have to use an enum instead of a string for temporary
storage:
string foo2(alias T, string s)(){
enum x = to!string(T) ~ s ~ ;
pragma(msg, x);
return x;
}
the problems i currently face during CTFE are more like:
a) in some cases manifest enums are broken in that they don't contain working
compile time copypaste values. this is currently the case for TypeTuples. i
think this will be fixed in the next DMD release.
b) pragma(msg) has not the same behavior as write() when it comes to formating
the output of non-string values, it sometimes needs help, e.g. with a
to!string() call.
Re: more enum and pragma troubles
On 2013-08-17 21:54, JS wrote: On Sunday, 18 August 2013 at 00:17:22 UTC, captaindet wrote: On 2013-08-17 14:36, Jesse Phillips wrote: Third you've declared a variable, bar, which will store your enumerated value, 4. Variables are not compile time, even if the value stored came from a compile time known value. yep, it completely escaped me that these are 'normal' variables. and i have realized now that i can make them known at compile time the same way as is done for other 'normal' variables, by declaring them const ;) But if they are const then what good does that do you? Just use an alias or enum in the first place? to be honest, i have not found a use case ;) highest priority was that i understood what was going on here... how did i get there? i was looking for an easy way to get pragma(msg,...) to print the given name for an enumerated value. in this example test2 or test4 instead of 2 and 4 - just like write is doing it at runtime. so i was playing around with the different variants of enum to see if i could get it working somehow.. and got sidetracked in the end i stuck to manifest constant enums storing the enumerated values and found that pragma( msg, to!string(foo) ); is doing the trick. /det
Re: more enum and pragma troubles
[enum foo = Test.test2;]
On 2013-08-17 01:03, JS wrote:
pragma( msg, foo ); // why does it print: cast(Test)2
// it should be: test2
// or at least simply: 2
It is 2! Notice the 2 at the end? The cast is just mumbo jumbo due to
the the compiler deals with the stuff. You can remove the casts
manually if you don't like them.
i saw the 2, but foo semantically contains a Test Test.test2 (this is the idea)
or technically an int 2. don't understand why pragma displays an explicit cast
here. maybe some internals that are leaking through the pragma(msg,...)
implementation.
// pragma( msg, bar ); // Error: variable bar cannot be read at compile time
Because bar is not a compile time constant. It is an runtime object.
pragma can't display certain things that it doesn't know about due to
the way the compiler works. It's unfortunate in some cases that it
simply doesn't work correctly, in others, such as this, it works as
expected.
You could argue that the compiler should know that bar is known at
compile time up to the pragma, and I would agree... but the compiler
simply isn't that smart.
but this is my very point! my understanding was that enums are all compile time
entities that are just copied around. at compile time. a named enum type should
make no difference. where is it documented that named enums become runtime
objects?
but you are right that this seems to be the case here and that pragma(msg,...)
is off the hook this time:
enum Test{
test2 = 2,
test4 = 4
}
enum foo = Test.test2;
Test bar = Test.test4;
// enum wtf = bar; // Error: variable bar cannot be read at compile time
/det
Re: more enum and pragma troubles
On 2013-08-17 01:51, captaindet wrote: named enums become runtime objects - named enums become runtime *only* objects
Re: more enum and pragma troubles
On 2013-08-17 01:51, captaindet wrote:
my understanding was that enums are all compile time entities that
are just copied around. at compile time. a named enum type should
make no difference.
oh i see now, naming them is just creating a disguise for the base type. then
they can become compile-time-known when declared const (see below). only
anonymous enum (manifest constant) are true compile time objects. reminds me of
my (type)tuple confusion. two completely different animals/concepts, with
similar/confusing syntax and blurry docs.
module demo;
import std.stdio;
enum Test{
test2 = 2,
test4 = 4
}
enum foo = Test.test2;
const Test bar = Test.test4;// does the trick
enum wtf = bar;
pragma( msg, foo ); // prints: cast(Test)2
pragma( msg, bar ); // pritns: cast(Test)4
void main(){
writeln( typeof(foo).stringof, = , foo ); // prints: Test = test2
writeln( typeof(bar).stringof, = , bar ); // prints: const(Test) =
test4
}
Re: more enum and pragma troubles
On 2013-08-17 14:36, Jesse Phillips wrote: Third you've declared a variable, bar, which will store your enumerated value, 4. Variables are not compile time, even if the value stored came from a compile time known value. yep, it completely escaped me that these are 'normal' variables. and i have realized now that i can make them known at compile time the same way as is done for other 'normal' variables, by declaring them const ;) pragma( msg, foo ); // why does it print: cast(Test)2 You are referring to a manifest constant, this is a simple textual replacement. Enumerations are typed, 2 is not a Test, so the compiler will write out a cast so the type system is happy. Similarly Test.test2 is not the value of foo, foo is a signal to the compiler to insert cast(Test)2. Hope that makes sense. things are becoming clearer now. thanks for your explanation, jesse! /det
Re: Tuple/TypeTuple etc.
On 2013-08-16 13:10, Ali Çehreli wrote: On 08/16/2013 09:27 AM, H. S. Teoh wrote: The so-called typetuple (what dmd calls a tuple) is a compile-time construct that can contain types, aliases, compile-time values, etc., that only exist at compile-time. They are all symbols, right? And symbols live only at compile time. ... Sequence is OK, but risks confusion with std.range.sequence. Is there a better word for it? Maybe an acronym -- CTS (compile-time sequence)? SymbolTuple it is! :) Ali other posts made the point that it should not have tuple in the word at all. so what about just symbols? i would be happy to see it as a fully explained and supported language feature. then symbols could even be a key word in D and used without !. it seems that all proposed short syntaxes have issues anyway, and i don't find symbols(int,string,3,foo) too verbose. /det
Re: A Discussion of Tuple Syntax
On 2013-08-16 20:02, Meta wrote:
On Friday, 16 August 2013 at 23:48:53 UTC, bearophile wrote:
- #(a, b) is unambiguous and would probably be the easiest option. I don't
think it looks too bad, but some people might find it ugly and noisy
It looks nice (but I don't know if it's technically usable), I have added it at
the end of the list of alternative syntaxes:
http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax
Why do you say that? It seems to me that it would be better than {}, because
there's only 1 other language construct that uses #, so there's little overlap
with other features.
not sure what we are talking about here, new syntax for
a) TypeTuple (that would be my best guess but i am not sure)
b) std.typecons.Tuple
c) both, a unified syntax
the DIP is not completely clear about this either.
only case (a) is hot at the moment and i fell into some related pits recently
myself. so i'd love to have a better syntax, one that makes the dirty hack
(status quo) a proper part of the language - as it is widely used already and
very powerful.
i am curious too if ..(..) constructs are completely out of the question. if
not, i would suggest as shorthand:
!(a,b)
this reminds of template instantiation and is exactly how the
awkwardly/confusingly named TypeTuple is realized now, as an alias to its own
template arguments. if we need a name for it, it should not remind at all of
'tuple' - since there is also the completely unrelated std.typecons.Tuple. a
more verbose/explicit suggestion would be
symbols(a,b)
/det
more enum and pragma troubles
are these bugs or expected behavior? (2 issues, see code below)
i thought enums are just compile time copypaste magic so i cannot think of a
reason why it should not be available at compile time...
if buggy, what is broken, enum (really bad) or pragma(msg,...) (worse enough)?
and are they in bugzilla already? (looked but nothing caught my eye)
if expected behavior, can someone pls explain.
cheers /det
import std.stdio;
enum Test{
test2 = 2,
test4 = 4
}
enum foo = Test.test2;
Test bar = Test.test4;
pragma( msg, foo ); // why does it print: cast(Test)2
// it should be: test2
// or at least simply: 2
// pragma( msg, bar ); // Error: variable bar cannot be read at
compile time
void main(){
writeln( typeof(foo).stringof, = , foo );
// prints as expected: Test = test2
writeln( typeof(bar).stringof, = , bar );
// prints as expected: Test = test4
}
Re: Ideas for a brand new widget toolkit
On 2013-08-13 08:23, Paul Z. Barsan wrote: Now let me complete these notes: * I think that porting an anonymous toolkit to D will do more harm than good because if the original project was lacking some features then clients will think that the ported version lacks them as well. If we want to take this route then, besides Harmonia and FOX tk, we might borrow things from FLTK(Fast Light Toolkit) * If the projects starts from zero, with its own design and is shiny new then people will be more attracted. * Even if we don't port a toolkit we can still get inspired to see how they interact with the underlying system. For example, we can take a look over the SDL way of handling input. * for drawing primitives we can use Cairo(curently used by GTK) or libX11 on linux and Directx on windows.Bindings for cairo and libX11 are provided by Deimos. I'm not sure if we can use OpenGL because it requires a rendering window or it renders in fullscreen mode.That rendering window can be provided by other toolkits but I don't think we want to depend on them. The OS window manager(xorg on linux) needs to keep track of the things it draws on its root window or surface and must be aware what to clean-up after you close your program. So the layer beneath this widget toolkit on Linux would be X(libX11). * XAML is being developed by Microsoft and XUL by Mozzilla. I think XUL is a better choice for a markup language and more friendlier with an open source toolkit. It would be pretty nice if we can make the GuiParser and abstract class and provide an implementation for XUL because that will allow us to write an implementation for the QML(Qt) aswell or other flavors of layout and style files. * If we want the project to scale up nicely then we should do things by the book. That is doing some research to see what technologies are involved, what the client programmers want(this thread) and then write some specs. * After we have the specs then we can start designing the toolkit using UML diagrams such that we will end up with a clean API and avoid future re-factoring. For UML designs, I recommend this web app https://www.draw.io/ which saves its files in XML format and we can store them in the git repository. * Only after we have a good design we will begin the actual coding. * there is this 3D modelling tool called Blender which has a modern-looking UI. People have been wondering if that GUI can be used as a library and the answer is no because the gui is harcoded into Blender. If our default ui look resembles that one(not necessarily identical) then we will gain more clients.Maybe we can even get support from its huge community of artists. Take a look: http://www.blender.org/features-gallery/features/ * this toolkit can complement DWT because DWT will provide native look and this one will provide the same look on all platforms. i like your ideas, especially the the clear top-down strategy. if the vision, i.e. design/API and roadmap is clear, and the documentation is good from the very beginning (something i want to stress particularly), then it could develop some dynamic. to ppl shrugging it off with the arguments that it is too much work or has been tried before: well, these arguments cancel each other out. previous projects have been very promising and accomplished a lot, enough for a kickstart. in theory - as it did not happen. and why? i think their biggest problem was that they were basically one man projects, not community projects. they did not outline design goals, open issues, roadmaps, - heck they did not even provide a sufficient documentation for using them. so they more or less died once the original maintainer lost interest. i often think what nice a D GUI package we would have by now if those 3 or 4 ppl running the previous attempts would have worked together. i played a bit with DFL some years ago and was quite impressed (it even had a GUI designer!) - but only to a certain point. i wanted multi platform and being only the occasional programmer, i need a good, detailed documentation. so back than i decided to not use D altogether as a GUI was a must for my application. (the core procedures being in C i still hope to move it to D at one point though) having a D-simple and D-safe pure D GUI is worth a try and would boost D's popularity. if it takes 2 years before it is usable, so what. it would not slow down improving D in other aspects as i think a GUI development would motivate a different set of ppl to contribute, i.e. would not withdraw current phobos and compiler devs. just my 2c, det
Re: enum and tuples
I'm pretty sure that this is just a bad error message.
void main(){
writeln(ok: , ok, ok[0]: , ok[0]);
// ok: Tuple!(string, string, string)(one, two, three)
ok[0]:
one
writeln(er: , er, er[0]: , er[0]);
// er: onetwothree er[0]: one
}
What I expect is happening is that TypeTuples don't convert to
string, so the
pragma fails,
hmm, but it is a TypeTuple of strings and aren't they supposed to
automatically expand? and pragma(msg, ...) takes various
arguments, e.g.
pragma(msg, this, and, that);
so is it just a bad error message or a bug in pragma(msg, ...)?
(..,i know, pragmas are difficult to blame for anything as they
are not part of the language proper. but in lieu of a compile
time print this is all we got for debugging our meta stuff.)
then there is the thing of assigning value type TypeTuples to
variables/enums. is this allowed or not? see my observations
regarding enums which are for 2.063.2. according to anonymous in
the git head for 2.064 the enum example for string value
TypeTuples now fails...i don't think any of this behavior is
documented anywhere. what i think is missing is a clearly defined
boundary/set of rules for what we can do with the internal
tuples (aka TypeTuples) and how, and what not.
/det
enum and tuples
hi,
i am still struggling getting to grips with tuples, especially typetuples. i
got into this when trying module introspection and the surprise discovery that
__traits(allMembers, .) seems to return a typetuple of strings. (the tuple
article on dlang and philippe's template tutorial do help a bit, but only so
much.)
typetuples seem to live in a shadow world and quite obscurely should be referred
to/passed around via aliases. even though we have alias a = b now i regard this as an
irregularity/oddity of the language, i.e. that they are not treated the same way as
variables/aggregates. anyhow, i started playing a bit putting them in enums anyway.
surprisingly, storing tuples and typetuples in enums is accepted by the
compiler. however, while enum tuples seem to behave normal/useful at compile time and run
time, enum'ed typetuples don't like compile time, but seem to behave at runtime. (i
rather would have expected the other way around). examples further below.
so i guess my questions are
a) if we are not allowed to put typetuples in enums, why is it not an error?
b) if enums are supposed to handle typetuples, why is it not working at compile
time?
/det
module demo;
import std.stdio, std.typetuple, std.typecons;
enum ok = tuple(one, two, three);
pragma(msg, ok, , , ok[0]);
// Tuple(one, two, three), one
enum er = TypeTuple!(one, two, three);
// pragma(msg, er);
// Error: variable _er_field_0,1,2 cannot be read at compile time
void main(){
writeln(ok: , ok, ok[0]: , ok[0]);
// ok: Tuple!(string, string, string)(one, two, three)
ok[0]: one
writeln(er: , er, er[0]: , er[0]);
// er: onetwothree er[0]: one
}
Re: enum and tuples
On 2013-08-09 11:36, Ali Çehreli wrote:
as I am in the process of revising and translating a Tuples chapter.
thanks for the reply, Ali.
as a matter of fact, i am checking your website regularly, eagerly awaiting the
translations of the tuples chapter. and the __traits and the template chapter
too ;)
your examples make things a bit clearer in general, but not in the specific
case of enums. i investigated my enum cases a bit more and it seems that enums
of string value typetuples are good-natured expression by far and large, only
pragma(msg, X) fails terribly.
enum X = TypeTuple!(only, strings, here); // fine everywhere but
pragma(msg
hovever, enums of integer or float value typetuples throw a phobos error when
appearing outside of main(), but work alright within main()
enum er = TypeTuple!(1,2,3);// ...\utf.d(1147): Error: cannot cast int to
(int, int, int)
void main(){
enum er = TypeTuple!(1,2,3);// fine
}
quite mysterious.
/det
Re: bug reporting
On 2013-08-03 18:29, captaindet wrote: recently i inadvertently created some noise in the bug reporting/tracking system. i had run into an ICE after using '__MODULE__' in a certain way. before reporting the bug, i did enter '__MODULE__' in the search mask of the tracking system but got no hit. so i thought it was a new issue and reported it. turns out this bug was reported before and the issue was resolved 2 weeks ago. what i did not know then (but found out now) was that after the 0-hit search i should have clicked the innocent looking 'edit search' link, which is actually an 'advanced search' feature - then latest* i would have realized that the default search excluded resolved issues, activated them, and then found out about the issue being reported and resolved already. i think it is an easy pit to fall into, at least for first time reporters. i'd like to suggest some improvements to the tracking interface: 1 'edit search' should be 'advanced search' as it is the standard name for this 2a make the default search to include resolved issues or b even let the 'report new bug' link direct to the advanced search already or c put up a brief explanation how ppl have to search the database properly before reporting a bug i felt sorry for having wasted my time with reporting a resolved issue and even worse of course for having wasted some developer's time for straightening the records. /det * yes, the default search results list which bug statuses were included in the search and that 'resolved' or 'closed' was not among them...but it is so easy to overlook something that is not there... i just realized the the actual entry point for the issue tracking, i.e. http://d.puremagic.com/issues is much more helpful/useful than the bug reporting link put on the dlang 'bug tracker' webpage ( http://dlang.org/bugstats.php ), i.e. http://d.puremagic.com/issues/enter_bug.cgi?product=D with the latter, as far as i can see, being the only link from dlang to the issue tracker. weird. i think dlang should link to the overview page of the issue tracker (first of the two links above). /det
Re: bug reporting
On 2013-08-05 15:53, Jesse Phillips wrote: On Monday, 5 August 2013 at 20:44:07 UTC, captaindet wrote: i just realized the the actual entry point for the issue tracking, i.e. http://d.puremagic.com/issues is much more helpful/useful than the bug reporting link put on the dlang 'bug tracker' webpage ( http://dlang.org/bugstats.php ), i.e. http://d.puremagic.com/issues/enter_bug.cgi?product=D with the latter, as far as i can see, being the only link from dlang to the issue tracker. weird. i think dlang should link to the overview page of the issue tracker (first of the two links above). /det Enter a bug report :) done ;)
bug reporting
recently i inadvertently created some noise in the bug reporting/tracking system. i had run into an ICE after using '__MODULE__' in a certain way. before reporting the bug, i did enter '__MODULE__' in the search mask of the tracking system but got no hit. so i thought it was a new issue and reported it. turns out this bug was reported before and the issue was resolved 2 weeks ago. what i did not know then (but found out now) was that after the 0-hit search i should have clicked the innocent looking 'edit search' link, which is actually an 'advanced search' feature - then latest* i would have realized that the default search excluded resolved issues, activated them, and then found out about the issue being reported and resolved already. i think it is an easy pit to fall into, at least for first time reporters. i'd like to suggest some improvements to the tracking interface: 1 'edit search' should be 'advanced search' as it is the standard name for this 2a make the default search to include resolved issues or b even let the 'report new bug' link direct to the advanced search already or c put up a brief explanation how ppl have to search the database properly before reporting a bug i felt sorry for having wasted my time with reporting a resolved issue and even worse of course for having wasted some developer's time for straightening the records. /det * yes, the default search results list which bug statuses were included in the search and that 'resolved' or 'closed' was not among them...but it is so easy to overlook something that is not there...
Re: Reading a structured binary file?
On 2013-08-02 17:13, Jonathan M Davis wrote: On Friday, August 02, 2013 19:49:54 Gary Willoughby wrote: What library commands do i use to read from a structured binary file? I want to read the byte stream 1, 2 maybe 4 bytes at a time and cast these to bytes, shorts and ints respectively. I can't seem to find anything like readByte(). I'd probably use std.mmfile and std.bitmanip to do it. MmFile will allow you to efficiently operate on the file as a ubyte[] in memory thanks to mmap, and std.bitmanip's peek and read functions make it easy to convert multiple bytes into integral values. - Jonathan M Davis FWIW i have to deal with big data files that can be a few GB. for some data analysis software i wrote in C a while back i did some testing with caching and such. turns out that for Win7-64 the automatic caching done by the OS is really good and any attempt to speed things up actually slowed it down. no kidding, i have seen more than 2GB of data being automatically cached. of course the system RAM must be larger than the file size (if i remember my tests correctly by a factor of ~2, but this is maybe not a linear relationship, i did not actually change the RAM just the size of the data file) and it will hold it in the cache only as long as there are no concurrent applications requiring RAM or caching. i guess my point is, if your target is Win7 and your files are 5x smaller than the installed RAM i would not bother at all trying to optimize file access. i suppose -nix machine will do a similar good job these days. /det
hyphenator.js vs dlang.org
i get an error now on dlang.org: dlang.org Hyphenator.js says: An Error occurred: QUOTA_EXCEEDED_ERR since it re-appears for every sup-page i now have to disable JS altogether for dlang. there must have been a change to the website during the last ~2 days, maybe as a follow-up on the 'working on the dlang.org website' thread. i know, i know, if i enable localStorage in my browser, the error message disappears. but it is switched off for a reason and will stay off. point is, i don't understand why Hyphenator.js all of a sudden wants to save data on my computer. most important, i thought the bottom line of the 'working on the dlang.org website' thread was that everyone is sick of Hyphenator.js and wants it to be taken out. please do so ASAP. /det
Re: working on the dlang.org website
On 2013-07-15 20:48, Brad Anderson wrote: unfortunately, do not support CSS3 hyphens so they still use the slow hyphenator.js. pls remove hyphenator.js altogehter. i see everyone complaining about it and no one wanting it. the words in the english language are usually short enough so that hyphenation is not really necessary. cheers, det
Re: reading a structure (eg header info) from file
thanks everyone for your help! i should have mentioned that i did play with std.stdio.File.readf and rawRead but was too thick to figure out a working solution. o i could not figure out how to make readf work with my self defined struct o same with rawRead. but here i understand my mistake now: i have to pass an array of my struct, even if i only want to read it once. endianness and padding are certainly issues. i have spent some time figuring out how to adjust struct packing in D. my definitions are now full of align(2) declarations... as for the endianness, as i can oversee it now all potential users will sit on little-endian machines. the group of users is small, just our workgroup. the datafiles in question are produced by some 3rd party 16bit windows software, so i have to accept the way the data is stored in the file. also, they can be as big as 2GB so reading in the whole file is not an option. thanks again, det
reading a structure (eg header info) from file
hi,
whilst converting some of my C code into D i got stuck.
in C:
typedef struct { /* info */ } INFO;
INFO info;
size_t checkio;
// read INFO from data file:
pf_datafile = fopen(datafile,rb);
checkio = fread((char *) info, sizeof(info), 1, pf_datafile);
how do i do this in D? i'd like to avoid falling back to calling C functions,
but i cannot figure out how do this with phobos functions. mind you, eventually
the INFO struct might be anywhere in the file, not only at the beginning.
cheers,
det
Re: [dmd-beta] dmd 2.063.2 beta 2 - windows help broken
On 2013-06-14 01:08, Vladimir Panteleev wrote: On Friday, 14 June 2013 at 03:45:37 UTC, captaindet wrote: the changelog page does load very slowly though (and my computer is not the weakest one...), some other pages are a bit sluggish too. earlier chm helps were very responsive. i guess it is the (increased) use of javascript on the dlang website. do we really need so much of it? and does it all have to go in the chm file? i would not mind a more austere appearance for a simple offline help. but this is probably easier said than done. The lag is caused by the hyphenation script. It inserts soft hyphens to allow line breaks inside words. It is often the target of complaints (such as adversely affecting performance, or being incompatible with certain browsers). I'll disable hyphenation in the CHM file, since this problem is especially grave due to the low JavaScript performance of the IE version used in the CHM reader. Here is a new version: http://dump.thecybershadow.net/3b3a645e610038cb40eb8ea1cad8fa07/d.chm impressive! now it has the speed and usability of the older chm help files. thanks for your work on this! /det
