Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:04:51 UTC, John Colvin wrote: Eww. auto arr = new int[3]; Also, I think he's referring to something slightly different. IMO, that shouldn't be too difficult to promote that on stack if the reference do not escape in most cases.
Re: IMAP library
On Monday, 13 April 2015 at 14:31:56 UTC, Johannes Pfau wrote: Am Sun, 12 Apr 2015 17:27:31 + schrieb Jens Bauer doc...@who.no: I won't say it's impossible, but it would be cumbersome processing email on an AVR. There are HTTP servers for AVR(8bit) devices, so it should be possible. That's absolutely true, but usually they're very simple. You can interface the AVR to an external SRAM or NOR-flash and thus store the entire email (or Web-page) there. But imagine that someone sends an email with an attachment - or just writes 50K of babbling. -That might be difficult if you have an AVR with only 8K RAM. It's much easier - and perhaps cheaper - to pick a Cortex-M, which has most of the things you need already; you can get ethernet PHYs for less than $2, which interfaces with a Cortex-M.
Re: DlangUI
On Monday, 13 April 2015 at 18:35:59 UTC, Vadim Lopatin wrote:
On Monday, 13 April 2015 at 17:51:54 UTC, John Colvin wrote:
On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote:
Hello!
I would like to announce my project, DlangUI library -
cross-platform GUI for D.
https://github.com/buggins/dlangui
License: Boost License 1.0
Native library written in D (not a wrapper to other GUI
library) - easy to extend.
As a backend, uses SDL2 on any platform, Win32 API on
Windows, XCB on Linux. Other backends can be added easy.
Tested on Windows and Linux.
Supports hardware acceleration - drawing using OpenGL when
built with version=USE_OPENGL.
Unicode support.
Internationalization support.
Uses Win32 API fonts on Windows, and FreeType on other
platforms.
Same look and feel can be achieved on all platforms.
Flexible look and feel - themes and styles.
API is a bit similar to Android UI.
Flexible layout, support of different screen DPI, scaling.
Uses two phase layout like in Android.
Supports drawable resources in .png and .jpeg, nine-patch
pngs and state drawables like in Android.
Single threaded. Use other threads for performing slow tasks.
Mouse oriented.
Actually, it's a port (with major redesign) of my library
used for cross-platform version of my application CoolReader
from C++.
State of project: alpha. But, already can be used for simple
2D games and simple GUI apps.
I'm keeping in mind a goal to write D language IDE based on
dlangui. :)
Adding support of 3D graphics is planned.
Currently implemented widgets:
TextWidget - simple static text (TODO: implement multiline
formatting)
ImageWidget - static image
Button - simple button with text label
ImageButton - image only button
TextImageButton - button with icon and label
CheckBox - check button with label
RadioButton - radio button with label
EditLine - single line edit
EditBox - multiline editor
VSpacer - vertical spacer - just an empty widget with
layoutHeight == FILL_PARENT, to fill vertical space in layouts
HSpacer - horizontal spacer - just an empty widget with
layoutWidth == FILL_PARENT, to fill horizontal space in
layouts
ScrollBar - scroll bar
TabControl - tabs widget, allows to select one of tabs
TabHost - container for pages controlled by TabControl
TabWidget - combination of TabControl and TabHost
Layouts - Similar to layouts in Android
LinearLayout - layout children horizontally or vertically
depending on orientation
VerticalLayout - just a LinearLayout with vertical orientation
HorizontalLayout - just a LinearLayout with vertical
orientation
FrameLayout - all children occupy the same place; usually
onle one of them is visible
TableLayout - children are aligned into rows and columns of
table
List Views - similar to lists in Android UI API.
ListWidget - layout dynamic items horizontally or vertically
(one in row/column) with automatic scrollbar; can reuse
widgets for similar items
ListAdapter - interface to provide data and widgets for
ListWidget
WidgetListAdapter - simple implementation of ListAdapter
interface - just a list of widgets (one per list item) to show
Sample project, example1 contains demo code for most of
dlangui API.
Try it using DUB:
git clone https://github.com/buggins/dlangui.git
cd dlangui
dub run dlangui:example1
Fonts note: on Linux, several .TTFs are loaded from hardcoded
paths (suitable for Ubuntu).
TODO: add fontconfig support to access all available system
fonts.
Helloworld:
// main.d
import dlangui.all;
mixin DLANGUI_ENTRY_POINT;
/// entry point for dlangui based application
extern (C) int UIAppMain(string[] args) {
// resource directory search paths
string[] resourceDirs = [
appendPath(exePath, ../res/), // for Visual D and
DUB builds
appendPath(exePath, ../../res/) // for Mono-D builds
];
// setup resource directories - will use only existing
directories
Platform.instance.resourceDirs = resourceDirs;
// select translation file - for english language
Platform.instance.uiLanguage = en;
// load theme from file theme_default.xml
Platform.instance.uiTheme = theme_default;
// create window
Window window = Platform.instance.createWindow(My Window,
null);
// create some widget to show in window
window.mainWidget = (new Button()).text(Hello
worldd).textColor(0xFF); // red text
// show window
window.show();
// run message loop
return Platform.instance.enterMessageLoop();
}
DDOC generated documentation can be found there:
https://github.com/buggins/dlangui/tree/master/docs
For more info see readme and example1 code.
I would be glad to see any feedback.
Can this project be useful for someone? What features/widgets
are must have for you?
Best regards,
Vadim coolreader@gmail.com
Is there any way I can debug a unittest build? Start
Debugging seems bound to the debug build.
Are asking about DlangIDE?
There is no debugging here at all.
Start Debugging currently just exdecutes
[Issue 14402] std.conv.emplace segfaults for nested class
https://issues.dlang.org/show_bug.cgi?id=14402 weaselcat r9shacklef...@gmail.com changed: What|Removed |Added CC||r9shacklef...@gmail.com --
Re: Probably you can run a D command line app on an android ARM device
Am Mon, 13 Apr 2015 17:44:41 + schrieb Laeeth Isharc laeeth.nos...@nospam-laeeth.com: On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote: On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote: BTW - since we have linux on ARM, the following may be useful if you wish to run a D application on your Android mobile device. No ADB or root required. http://kevinboone.net/android_nonroot.html I stumbled across that site sometime back when looking for a way to open a shell with my own command-line apps on my Android tablet and run the druntime/phobos unit tests from the command line on an unrooted Android/ARM device. However, that setup is not going to fix the TLS issue that's holding up Android/ARM. D sticks all non-shared/__gshared globals in Thread-Local Storage (TLS) by default, but Android doesn't support TLS natively, so you can't just compile a D app for linux/ARM and run it on Android/ARM, whether with that setup or not. So that is why vibed demo app doesn't work although it does compile. (The TLS kludge not yet in GDC). So if I make all globall gshared, I can do useful work today using Gdc on arm android, even if I have to use an alternative to vibed for the network stuff ? I didn't read all of this discussion. Does the chroot method mean you can use glibc? Anyway, I recently pushed GC support for GCC emulated TLS to GDC which should work just fine on bionic or glibc. However, the GC doesn't work with bionic because of other issues. So your best bet is to build an ARM GDC-compiler with --disable-tls. This way you at least get emulated TLS which should work.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 19:10:28 UTC, Steven Schveighoffer
wrote:
It would be nice if alloca could be wrapped so it could be made
safe(r).
string stackArray(T)(string name, string len) {
import std.format : format;
return q{
import core.stdc.stdlib : alloca;
import std.conv : emplace;
size_t %2$s_length_ = %3$s;
%1$s* %2$s_storage_ = cast(%1$s*) alloca(%2$s_length_ *
%1$s.sizeof);
%1$s[] %2$s = %2$s_storage_[0 .. %2$s_length_];
foreach(ref ele; %2$s)
emplace(ele);
}.format(T.stringof, name, len);
}
void main(string[] args)
{
import std.conv : to;
import std.stdio : writefln;
mixin(stackArray!int(arr, q{ args[1].to!size_t }));
writefln(allocated an array of %s bytes, arr.length);
writefln(arr = %s, arr);
}
This is the best I can come up with currently. I think with a
@forceinline attribute, it would be a lot better, assuming
`alloca()` is usable inside an inlined method.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:56:57 UTC, Steven Schveighoffer wrote: No, just g++ (and i believe this is clang) -Steve Clang tracks gcc, but it isn't C++ and therefore not portable: Variable length arrays are not currently supported in Visual C++. https://msdn.microsoft.com/en-us/library/zb1574zs.aspx
Re: Does 'D' language supports 'C' like VLA?
On 4/13/15 1:51 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Monday, 13 April 2015 at 17:24:38 UTC, Steven Schveighoffer wrote: Note, it's best to show when comparing C/C++ to D the C++ code and how you expect it to work too. Did you compile C++ with strict/pedantic options? ( I don't think it should work in compliant C++ ) No, just g++ (and i believe this is clang) -Steve
Re: Does 'D' language supports 'C' like VLA?
On 4/13/15 1:34 PM, BS LD wrote: On Monday, 13 April 2015 at 17:24:38 UTC, Steven Schveighoffer wrote: D doesn't do this, you have to know the size of the stack array at compile time. You can use alloca, which will give you some runtime allocation of stack, but it can be dangerous (as noted). I don't know how things are handled here but it will be very nice if someone could make the language support this. It's very unlikely this will make it into the language. Alloca should be good enough for this, it's not a very common usage, and supporting it is not easy. Value range propagation (the compiler understanding what values a variable can be at some point in time) only is inside one statement. It does not remember what szArr can be at a later statement. Although I think it will be a nice feature if it can. I would prefer slower compilation then slower code. It requires flow analysis, and that is not something I think any of the compiler devs are willing to add at this point. -Steve
[Issue 14424] [REG2.066] dmd crashes with __traits(getUnitTests)
https://issues.dlang.org/show_bug.cgi?id=14424 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz Hardware|x86_64 |All Summary|dmd crashes with|[REG2.066] dmd crashes with |__traits(getUnitTests) |__traits(getUnitTests) --
Re: Implementing cent/ucent...
On Monday, 13 April 2015 at 09:00:30 UTC, Dominikus Dittes Scherkl wrote: I once had added cent/ucent to std/traits.d TypeInfo for cent/ucent is now in druntime. std.traits has cent/ucent support. I need to address some comments in std.format before it can be merged. Other modules (e.g. std.conv) still miss support. Regards, Kai
Re: DlangUI
On Monday, 13 April 2015 at 17:51:54 UTC, John Colvin wrote:
On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote:
Hello!
I would like to announce my project, DlangUI library -
cross-platform GUI for D.
https://github.com/buggins/dlangui
License: Boost License 1.0
Native library written in D (not a wrapper to other GUI
library) - easy to extend.
As a backend, uses SDL2 on any platform, Win32 API on Windows,
XCB on Linux. Other backends can be added easy.
Tested on Windows and Linux.
Supports hardware acceleration - drawing using OpenGL when
built with version=USE_OPENGL.
Unicode support.
Internationalization support.
Uses Win32 API fonts on Windows, and FreeType on other
platforms.
Same look and feel can be achieved on all platforms.
Flexible look and feel - themes and styles.
API is a bit similar to Android UI.
Flexible layout, support of different screen DPI, scaling.
Uses two phase layout like in Android.
Supports drawable resources in .png and .jpeg, nine-patch pngs
and state drawables like in Android.
Single threaded. Use other threads for performing slow tasks.
Mouse oriented.
Actually, it's a port (with major redesign) of my library used
for cross-platform version of my application CoolReader from
C++.
State of project: alpha. But, already can be used for simple
2D games and simple GUI apps.
I'm keeping in mind a goal to write D language IDE based on
dlangui. :)
Adding support of 3D graphics is planned.
Currently implemented widgets:
TextWidget - simple static text (TODO: implement multiline
formatting)
ImageWidget - static image
Button - simple button with text label
ImageButton - image only button
TextImageButton - button with icon and label
CheckBox - check button with label
RadioButton - radio button with label
EditLine - single line edit
EditBox - multiline editor
VSpacer - vertical spacer - just an empty widget with
layoutHeight == FILL_PARENT, to fill vertical space in layouts
HSpacer - horizontal spacer - just an empty widget with
layoutWidth == FILL_PARENT, to fill horizontal space in layouts
ScrollBar - scroll bar
TabControl - tabs widget, allows to select one of tabs
TabHost - container for pages controlled by TabControl
TabWidget - combination of TabControl and TabHost
Layouts - Similar to layouts in Android
LinearLayout - layout children horizontally or vertically
depending on orientation
VerticalLayout - just a LinearLayout with vertical orientation
HorizontalLayout - just a LinearLayout with vertical
orientation
FrameLayout - all children occupy the same place; usually onle
one of them is visible
TableLayout - children are aligned into rows and columns of
table
List Views - similar to lists in Android UI API.
ListWidget - layout dynamic items horizontally or vertically
(one in row/column) with automatic scrollbar; can reuse
widgets for similar items
ListAdapter - interface to provide data and widgets for
ListWidget
WidgetListAdapter - simple implementation of ListAdapter
interface - just a list of widgets (one per list item) to show
Sample project, example1 contains demo code for most of
dlangui API.
Try it using DUB:
git clone https://github.com/buggins/dlangui.git
cd dlangui
dub run dlangui:example1
Fonts note: on Linux, several .TTFs are loaded from hardcoded
paths (suitable for Ubuntu).
TODO: add fontconfig support to access all available system
fonts.
Helloworld:
// main.d
import dlangui.all;
mixin DLANGUI_ENTRY_POINT;
/// entry point for dlangui based application
extern (C) int UIAppMain(string[] args) {
// resource directory search paths
string[] resourceDirs = [
appendPath(exePath, ../res/), // for Visual D and
DUB builds
appendPath(exePath, ../../res/) // for Mono-D builds
];
// setup resource directories - will use only existing
directories
Platform.instance.resourceDirs = resourceDirs;
// select translation file - for english language
Platform.instance.uiLanguage = en;
// load theme from file theme_default.xml
Platform.instance.uiTheme = theme_default;
// create window
Window window = Platform.instance.createWindow(My Window,
null);
// create some widget to show in window
window.mainWidget = (new Button()).text(Hello
worldd).textColor(0xFF); // red text
// show window
window.show();
// run message loop
return Platform.instance.enterMessageLoop();
}
DDOC generated documentation can be found there:
https://github.com/buggins/dlangui/tree/master/docs
For more info see readme and example1 code.
I would be glad to see any feedback.
Can this project be useful for someone? What features/widgets
are must have for you?
Best regards,
Vadim coolreader@gmail.com
Is there any way I can debug a unittest build? Start
Debugging seems bound to the debug build.
Are asking about DlangIDE?
There is no debugging here at all.
Start Debugging currently just exdecutes `dub run`
Re: Probably you can run a D command line app on an android ARM device
On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote: On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote: BTW - since we have linux on ARM, the following may be useful if you wish to run a D application on your Android mobile device. No ADB or root required. http://kevinboone.net/android_nonroot.html I stumbled across that site sometime back when looking for a way to open a shell with my own command-line apps on my Android tablet and run the druntime/phobos unit tests from the command line on an unrooted Android/ARM device. However, that setup is not going to fix the TLS issue that's holding up Android/ARM. D sticks all non-shared/__gshared globals in Thread-Local Storage (TLS) by default, but Android doesn't support TLS natively, so you can't just compile a D app for linux/ARM and run it on Android/ARM, whether with that setup or not. So that is why vibed demo app doesn't work although it does compile. (The TLS kludge not yet in GDC). So if I make all globall gshared, I can do useful work today using Gdc on arm android, even if I have to use an alternative to vibed for the network stuff ? I guess you might be able to run a local web server to have a friendlier interface, although I have not yet tried. Since ssh and rsync works, I don't see why a web server wouldn't. It'll likely work; you just can't run on port 80 because you don't have root. Fine with me to use another port... I am not trying to serve the world, just be able to interact via the browser rather than command line. The alternative is to run a full linux install in a chroot: https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy But that requires root, so you're back to square one. Well, I have root. But if I get somebody else to start playing with my app, I don't want to have to make them root their device just to see what it does. Laeeth.
Re: Does 'D' language supports 'C' like VLA?
On 4/13/15 2:55 PM, bearophile wrote: Steven Schveighoffer: It's very unlikely this will make it into the language. Alloca should be good enough for this, it's not a very common usage, and supporting it is not easy. alloca is bug-prone and unsafe, and if you want to create a 2D array on the stack it's not good enough. They are uncommonly used because they are not supported by the D compiler, and it doesn't track the memory ownership well enough. But a well designed system language needs to push programmers to use the stack as much as possible. It would be nice if alloca could be wrapped so it could be made safe(r). -Steve
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:53:24 UTC, John Colvin wrote: On Monday, 13 April 2015 at 17:51:27 UTC, Ola Fosheim Grøstad wrote: On Monday, 13 April 2015 at 17:24:38 UTC, Steven Schveighoffer wrote: Note, it's best to show when comparing C/C++ to D the C++ code and how you expect it to work too. Did you compile C++ with strict/pedantic options? ( I don't think it should work in compliant C++ ) Dunno about C++, but IIRC VLAs are part of the C99 standard. They were made optional in C11 due to the security risks and the emphasis in C11 to improve C's security. -- Paulo
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:32:31 UTC, Dmitri Makarov wrote:
On Monday, 13 April 2015 at 17:24:05 UTC, Dylan Knutson wrote:
On Monday, 13 April 2015 at 17:20:04 UTC, Dmitri Makarov wrote:
This should work the way you want it to:
void main()
{
immutable size_t szArr = 3;
int[szArr] arr;
}
Regards,
Dmitri
No, this isn't what VLA is. Ola Fosheim Grøstad has the right
of it; he'll need to use alloca to dynamically extend the
stack. What OP is referring to is the ability to create a
dynamically sized array on the stack, rather than the heap.
Here's a good description of what VLA is and how it works:
https://en.wikipedia.org/wiki/Variable-length_array
Ah, ok, then why did he complain that the compiler can't
determine that the value of szArr is known at compile-time. A
kind of conundrum, isn't it -- he want's to create arrays on
stack with their sizes known at run-time, but wants the
compiler to figure the size of such an array at compile-time...
Who wants the compiler creating un-efficient code? I supposed
that I would need to write more complex code in order to fool it
that 'szArr' isn't known at compile-time or even make it really
so.
Re: rant D's makefiles... /rant
On Monday, 13 April 2015 at 14:24:58 UTC, Dicebot wrote: I want to replace those with D scripts for a reason. Me too. Let's see if we can actually agree on how they'd end up looking, huh? ;) Atila
[Issue 14424] dmd crashes with __traits(getUnitTests)
https://issues.dlang.org/show_bug.cgi?id=14424 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added CC||and...@erdani.com Severity|critical|regression --
Re: I came up with a new logo for the D language
On 4/13/2015 12:12 AM, deadalnix wrote: It does not matter if one knows this is planets or not (these aren't planet technically, but phobos and deimos, mars's moons). What does matter is that the logo is recognized and associated with D. Any logo change goes against that goal, so that's probably won't happen. I appreciate the effort going into making a new logo, and it's always fun to do it and talk about it, but I like the existing one better (and I agree that constantly changing the logo is tantamount to not having one, making it pointless).
Re: Does 'D' language supports 'C' like VLA?
Steven Schveighoffer: It's very unlikely this will make it into the language. Alloca should be good enough for this, it's not a very common usage, and supporting it is not easy. alloca is bug-prone and unsafe, and if you want to create a 2D array on the stack it's not good enough. They are uncommonly used because they are not supported by the D compiler, and it doesn't track the memory ownership well enough. But a well designed system language needs to push programmers to use the stack as much as possible. Bye, bearophile
Re: D vs nim
Sorry if I don't make my point accurately, it's been not so long since I started learning English. I often found programming language community relates to churchs. I find D to be really present on reddit and that’s great because other people can discover that wonderful language. But blaming other language for doing the same is just plain hypocrite : if it's on top, people are interested, it's that simple. That been said I am not familiar with nim, but I am really excited about the next generation of languages like D and rust. To express my opinion about these language and note those are just *opinions*. I think D is extraordinary expressive...such a complex language too. From a metaprogramming point of view, I am mixed about string mixins, the syntax of the 'is' statement (seriously ?), do we need so many traits ? Rust opted for type classes over templates constraints and ast macros, D had no shame introducing imperative programming into the compile time word...it a choice and I kind of like even though some might think it's not really pretty. I don't like the GC much and I think I wouldn't missed the features it allowed, but that won't say I am very grateful about the recent improvements (I think it's Martin Nowak to thanks). I don't like associative arrays built-in, those are no trivial data structure and should be available in phobos. About Phobos, it's clearly a big win compare to Rust standard library...for now (only...I hope), ranges are plain awesome, algorithm is good. Modules, distinction between struct and class, ref and others storage classes well that's beyond word : awesome ! Unittests : thats political. ;) Foreach is good but why adding an index is restricted to built-in arrays and I know about ennumerate, that's not the question. Why auto ref arguments taking function should be templates (I understand there is a method duplication but that is so weird especially not coherent with auto ref *returning function) ? I have noticed something about D, sometimes some stuff might seems weird at first but often when you dig about it, you discover there is a really well thought design choice behind it. I don't now rust that much, but I have to admit it looks much prettier and a bit less expressive/powerful but again it's D I am comparing it to. The two are a great improvement on C++ I get my pittance with since four month now, that feels good. A bad think about those languages though is that they can also make you kinda hate your job sometimes. ;) Well anyway, thanks to all the people involved in the design of such heavy machineries as compilers, I hope I get more time and experience to help some day (I am more in applied maths, so I think I will try to get on this side). btw : I think D should get rid off un-bracketed if statement, programming is not about sparing the number of lines...but that’s again a matter of taste.
Re: I came up with a new logo for the D language
I rather liked the anthropomorphized D that used to be somewhere on the site.
Re: I came up with a new logo for the D language
On Monday, 13 April 2015 at 20:45:29 UTC, weaselcat wrote: I rather liked the anthropomorphized D that used to be somewhere on the site. This guy : http://dlang.org/overview.html
Re: I came up with a new logo for the D language
On Mon, Apr 13, 2015 at 08:49:13PM +, CraigDillabaugh via Digitalmars-d wrote: On Monday, 13 April 2015 at 20:45:29 UTC, weaselcat wrote: I rather liked the anthropomorphized D that used to be somewhere on the site. This guy : http://dlang.org/overview.html Here's my attempt to upgrade that mascot: http://eusebeia.dyndns.org/~hsteoh/tmp/mascot.png T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Re: I came up with a new logo for the D language
On Monday, 13 April 2015 at 20:25:21 UTC, Barry Smith wrote: On Monday, 13 April 2015 at 18:56:45 UTC, Walter Bright wrote: On 4/13/2015 12:12 AM, deadalnix wrote: It does not matter if one knows this is planets or not (these aren't planet technically, but phobos and deimos, mars's moons). What does matter is that the logo is recognized and associated with D. Any logo change goes against that goal, so that's probably won't happen. I appreciate the effort going into making a new logo, and it's always fun to do it and talk about it, but I like the existing one better (and I agree that constantly changing the logo is tantamount to not having one, making it pointless). Well, I guess that's that then. The master has decided. I think it's better to create logos for community events (like the latest DConf logo). Just for the record the upcoming D Hackathon needs more marketing. It would be good to attract some people from the outside. Piotrek
Re: I came up with a new logo for the D language
On 4/13/15 3:31 AM, ixid wrote: On Monday, 13 April 2015 at 07:12:29 UTC, deadalnix wrote: It does not matter if one knows this is planets or not (these aren't planet technically, but phobos and deimos, mars's moons). What does matter is that the logo is recognized and associated with D. Any logo change goes against that goal, so that's probably won't happen. Do you think anyone outside a tiny number of forum users would recognize the logo at this stage? Yes, it's on the site, which undergoes quite a few visits daily. Surprising details with my keynote at DConf 2015. -- Andrei
Re: Updated D TextMate bundle for D2 and TM2
On Monday, 13 April 2015 at 15:08:47 UTC, Jacob Carlborg wrote:
On 2015-04-13 13:39, biozic wrote:
Awesome!
The only quirk I can see so far is that `xxx yyy(` is always
parsed so
that yyy is considered to be the symbol of a function, is
highlighted as
such, and appears in the symbol tree. Is it a limitation of
Textmate?
No, it's more the order of how rules implemented. I know I had
this problem with static assert. The solution I used was to
added the rule for static assert before the rule for a
method. What particular code is there a problem with?
For example:
---
version (all)
{
struct foo { int i; }
auto bar()
{
static if (true) {}
static assert(true);
return foo(1);
}
}
---
In the body of the bar function, `if`, `assert` and `foo` are
parsed as a method definition and appear in the symbol tree.
Perhaps I should just move the rule for a method to be the last
rule.
Not enough I think. Rather, the method rule shouldn't match if
the method name is a keyword or if it starts with `return`. This
seems to work around these problems:
{ name = 'meta.definition.method.d';
begin = '(?x)^\s*(?!\breturn\b)
((?:\b(?:public|private|protected|package|static|final|synchronized|abstract|export|override|auto|nothrow|immutable|const|inout|ref|shared)\b\s*)*)
# modifier
(?:([^\s]+))\s+ # return type
((?!\bif\b)(?!\bassert\b)\w+)\s* #
identifier
(?=\()';
end = '(?={|;)';
beginCaptures = {
1 = { name = 'storage.modifier.d'; };
2 = { patterns = ( { include = '$base'; } ); };
3 = { name = 'entity.name.function.d'; };
};
patterns = (
{ include = '$base'; },
{ include = '#block'; },
);
},
Also, you forgot the `package` protection keyword (plus optional
identifier list) in several places.
Re: rant D's makefiles... /rant
On 4/13/15 7:34 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Apr 13, 2015 at 02:24:57PM +, Dicebot via Digitalmars-d wrote: I want to replace those with D scripts for a reason. Now that dmd is dependent on an existing version of dmd to build, it should be no problem to replace the makefiles with D code. Everytime something like this happens I just see all the flaws of makefiles all over again, but unfortunately some people just refuse the acknowledge that makefiles are going the way of the dinosaur and it's time to move on. A thought: any makefile replacement should make sure there's an equivalent to -j. My personal feeling: the build is really low on the priority list no matter how you sort it - except least impact stuff first :o) - and replacing makefiles with even the perfect solution won't improve anything measurably. Atila: make clean should work. Must have been something weird on your system. Andrei
Re: rant D's makefiles... /rant
On Monday, 13 April 2015 at 13:56:17 UTC, Russel Winder wrote: On Mon, 2015-04-13 at 13:12 +, Atila Neves via Digitalmars-d wrote: I did a `git up` on dmd, druntime and phobos, but phobos wouldn't build. Weird, but I had to fork phobos anyway, let me do that. Still wouldn't build. I tried `make clean`, can't remember exactly what happened but that didn't work either. In the end I `rm -rf`ed dmd and druntime, recloned them, rebuilt them and _then_ phobos could build. Feels like when I wrote Makefiles by hand, I'd forgotten it could get this bad. Make was a revelation and a revolution, in 1977. Things have progressed in the last 37 years. Sadly a large number of C, C++, D, etc. programmers seem to be convinced that build technology reached a pinnacle in 1992 and stopped progressing. To be fair, I've seen a lot of new build systems, but not a lot of better build system. I keep coming back to makefile, not because it is good, but because it is not worse than most of the shit I tried, and at least it is available everywhere and you find documentation about it on the net easily for everyone of its obscure corners.
Re: rant D's makefiles... /rant
On Monday, 13 April 2015 at 13:12:23 UTC, Atila Neves wrote: I did a `git up` on dmd, druntime and phobos, but phobos wouldn't build. Weird, but I had to fork phobos anyway, let me do that. Still wouldn't build. I tried `make clean`, can't remember exactly what happened but that didn't work either. In the end I `rm -rf`ed dmd and druntime, recloned them, rebuilt them and _then_ phobos could build. Feels like when I wrote Makefiles by hand, I'd forgotten it could get this bad. Atila I'd bet you had a dmd.conf left somewhere. I have one, all my build are broken.
Re: rant D's makefiles... /rant
On Monday, 13 April 2015 at 21:27:47 UTC, deadalnix wrote: To be fair, I've seen a lot of new build systems, but not a lot of better build system. I keep coming back to makefile, not because it is good, but because it is not worse than most of the shit I tried, and at least it is available everywhere and you find documentation about it on the net easily for everyone of its obscure corners. For the amount of complaining about make, there sure has been little process in making a better make.
[Issue 14433] std.encoding does not support Central European ISO-8859-2 and CP1250 encodings
https://issues.dlang.org/show_bug.cgi?id=14433 --- Comment #1 from Tomáš Chaloupka chalu...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/3173 --
Re: D Hackathon: April 25 - May 1
On 4/13/15 7:10 AM, Russel Winder via Digitalmars-d wrote: I can only make the D Hackathon 2015, on 2015-04-30 and 2015-05-01. I'd love to get stuck in on something. Probably best for me to find out the state of play (!) at 2015-04-30T06:00+01:00 and find out how/where to contribute then. Sounds great. See you on the barricades! -- Andrei
[Issue 14443] New: [Reg 2.067.0] Incorrect double freeing of reference counted struct
https://issues.dlang.org/show_bug.cgi?id=14443
Issue ID: 14443
Summary: [Reg 2.067.0] Incorrect double freeing of reference
counted struct
Product: D
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat bug.d CODE
import std.typecons;
struct Path
{
struct Payload
{
int p;
}
RefCounted!Payload _data;
unittest
{
auto path = Path(RefCounted!Payload(12));
assert(path._data.p == 12);
foreach(element; PathRange(path)) {}
}
}
struct PathRange
{
Path path;
size_t i;
@property empty()
{
return i 2;
}
void popFront()
{
++i;
}
@property PathElement front()
{
return PathElement(this, path._data.p);
}
}
struct PathElement
{
PathRange range;
this(PathRange range, int)
{
this.range = range;
}
}
CODE
dmd -main -unittest -run bug
This code works with 2.066.1 but segfaults with 2.067.0, apparently because the
refcount of _data in path drops to 0 while it's still used.
My malloc implementation also complains about a double free.
--
Re: D Hackathon: April 25 - May 1
On Monday, 13 April 2015 at 20:37:02 UTC, Andrei Alexandrescu wrote: On 4/13/15 7:10 AM, Russel Winder via Digitalmars-d wrote: I can only make the D Hackathon 2015, on 2015-04-30 and 2015-05-01. I'd love to get stuck in on something. Probably best for me to find out the state of play (!) at 2015-04-30T06:00+01:00 and find out how/where to contribute then. Sounds great. See you on the barricades! -- Andrei BTW. What do you mean here: Walter and I will observe them and invite others to join us: Piotrek
Re: I came up with a new logo for the D language
On 4/13/15 5:49 AM, Abdulhaq wrote: Only a small fraction of those people associate D with its current logo I think that's incorrect. A simple thought: if you have graphics talents and inclination there's a TON of opportunity to apply them all over dlang.org and dconf.org. Cue my desperate attempts for a good DConf logo and general look. Ironically the only untouchable part is the logo. (The one door you shouln't open...) Have at it. Just leave the logo alone. Andrei
cdb reader and creator
here is Cdb[1] reader and creator, in two small modules. reader: [2] creator: [3] sample: [4] it's totally untested, but i believe that is works. at least for the given sample. Public Domain, based on tinycdb[5]. [1] http://cr.yp.to/cdb.html [2] http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/tinycdb.d [3] http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/tinycdbmk.d [4] http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/tinycdb_test/cdbtest.d [5] http://www.corpit.ru/mjt/tinycdb.html signature.asc Description: PGP signature
Re: I came up with a new logo for the D language
On Monday, 13 April 2015 at 18:56:45 UTC, Walter Bright wrote: On 4/13/2015 12:12 AM, deadalnix wrote: It does not matter if one knows this is planets or not (these aren't planet technically, but phobos and deimos, mars's moons). What does matter is that the logo is recognized and associated with D. Any logo change goes against that goal, so that's probably won't happen. I appreciate the effort going into making a new logo, and it's always fun to do it and talk about it, but I like the existing one better (and I agree that constantly changing the logo is tantamount to not having one, making it pointless). Well, I guess that's that then. The master has decided.
Programming languages and performance
https://www.reddit.com/r/programming/comments/32f4as/why_most_high_level_languages_are_slow/ Good article, discussion is a bit lame.
Re: Programming languages and performance
On Monday, 13 April 2015 at 23:28:46 UTC, Walter Bright wrote: Good article, discussion is a bit lame. It's reddit, that's not really surprising.
Re: Programming languages and performance
On Mon, Apr 13, 2015 at 04:28:45PM -0700, Walter Bright via Digitalmars-d wrote: https://www.reddit.com/r/programming/comments/32f4as/why_most_high_level_languages_are_slow/ Good article, discussion is a bit lame. While Phobos is making good progress at being allocation-free, it still has a ways to go. And it doesn't help that the current D GC isn't that great, when you do have to allocate -- I've managed to get 30-40% performance improvements just by turning off the default collection schedule and triggering collections myself at more strategic intervals. Not having to box things is a big win IMO, though. Boxing of POD types in Java/C# just screams inefficient to me... can you imagine all that extra, needless indirection wreaking havoc on the CPU cache and cache predictions? Having first-class support for value types is also a big win. I rarely use classes in D except when I actually need polymorphism, which requires heap allocation. With alias this, you can even have a limited amount of inheritance in structs, which is totally cool. But at the end of the day, the programmer has to know how to write cache-efficient code. No matter how the language/compiler tries to be smart and do the Right Thing(tm), poorly-laid out data is poorly-laid out data, and you're gonna incur cache misses all over the place. Cache-unfriendly algorithms are cache-unfriendly algorithms, and no smart language design / smart optimizer is gonna fix that for you. You have to know how to work with the modern cache hierarchies, how to lay out data for efficient access, and how to write cache-friendly algorithms. To this end, I found the following series of articles extremely enlightening: http://lwn.net/Articles/250967/ T -- Music critic: That's an imitation fugue!
Re: Programming languages and performance
On Tuesday, 14 April 2015 at 02:12:18 UTC, Walter Bright wrote: On 4/13/2015 4:28 PM, Walter Bright wrote: https://www.reddit.com/r/programming/comments/32f4as/why_most_high_level_languages_are_slow/ Good article, discussion is a bit lame. One of the reasons I've been range-ifying Phobos is not only to remove dependence on the GC, but often to eliminate allocations entirely, by removing the need for temporaries to hold intermediate results. this is essentially fusion/deforestation, correct?
Re: Programming languages and performance
thanks for the links and colour, Walter and HST But at the end of the day, the programmer has to know how to write cache-efficient code. No matter how the language/compiler tries to be smart and do the Right Thing(tm), poorly-laid out data is poorly-laid out data, and you're gonna incur cache misses all over the place. Cache-unfriendly algorithms are cache-unfriendly algorithms, and no smart language design / smart optimizer is gonna fix that for you. You have to know how to work with the modern cache hierarchies, how to lay out data for efficient access, and how to write cache-friendly algorithms. While Phobos is making good progress at being allocation-free, it still has a ways to go. And it doesn't help that the current D GC isn't that great, when you do have to allocate -- I've managed to get 30-40% performance improvements just by turning off the default collection schedule and triggering collections myself at more strategic intervals. Would love to see an article sometime on efficient programming in D - both cache efficiency and how to make the GC your friend. (I get the basic idea of data driven design, but not yet the subtleties of cache efficient code and I am sure many other newcomers to D must be in a similar position). I found the same thing as you describe with a monster CSV import (files are daily, but data needs to be organized by symbol to be useful). Not having to box things is a big win IMO, though. Boxing of POD types in Java/C# just screams inefficient to me... can you imagine all that extra, needless indirection wreaking havoc on the CPU cache and cache predictions? There was an interesting post on Lambda the ultimate by Mike Pall (sp? The Lua guy) in which he said certain eyesight decisions in Python meant much harder to ever make Python fast, and one of the pypy guys agreed with him. (It was more than just boxing). I am not in favour of extrapolating trends mindlessly, but I wonder what the world looks like In five or ten years should the gap between processor perf and memory latency continue to widen at similar rates given continued growth in data set sizes. Laeeth.
[Issue 13460] dmd can no longer be built with DEBUG=1 on Linux/x86_64
https://issues.dlang.org/show_bug.cgi?id=13460 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Keywords||pull Status|NEW |RESOLVED CC||m...@krej.cz Hardware|x86 |x86_64 Resolution|--- |FIXED --
[Issue 14439] aa's keys, values, byKey, byValue not usable in @safe context
https://issues.dlang.org/show_bug.cgi?id=14439
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
Summary|aa's are essentially|aa's keys, values, byKey,
|unusable in @safe contexts |byValue not usable in @safe
||context
--- Comment #1 from Brad Roberts bra...@puremagic.com ---
module safeaa;
void main() @safe
{
string[string] saa = [ a : 1, b : 2 ];
string s = saa[a];
saa[c] = 3;
if (c in saa) {}
size_t l = saa.length;
foreach(k; saa.keys) {}
foreach(k; saa.byKey) {}
foreach(v; saa.values) {}
foreach(v; saa.byValue) {}
}
safeaa.d(15): Error: safe function 'D main' cannot call system function
'object.keys!(string[string], string, string).keys'
safeaa.d(17): Error: safe function 'D main' cannot call system function
'object.byKey!(string[string], string, string).byKey'
safeaa.d(17): Error: safe function 'D main' cannot call system function
'object.byKey!(string[string], string, string).byKey.Result.empty'
safeaa.d(17): Error: safe function 'D main' cannot call system function
'object.byKey!(string[string], string, string).byKey.Result.popFront'
safeaa.d(17): Error: safe function 'D main' cannot call system function
'object.byKey!(string[string], string, string).byKey.Result.front'
safeaa.d(19): Error: safe function 'D main' cannot call system function
'object.values!(string[string], string, string).values'
safeaa.d(21): Error: safe function 'D main' cannot call system function
'object.byValue!(string[string], string, string).byValue'
safeaa.d(21): Error: safe function 'D main' cannot call system function
'object.byValue!(string[string], string, string).byValue.Result.empty'
safeaa.d(21): Error: safe function 'D main' cannot call system function
'object.byValue!(string[string], string, string).byValue.Result.popFront'
safeaa.d(21): Error: safe function 'D main' cannot call system function
'object.byValue!(string[string], string, string).byValue.Result.front'
I'm not sure why saa.length builds since _aaLen isn't marked @safe. Probably
the compiler making assumptions that the code doesn't declare.
--
Re: I came up with a new logo for the D language
On 4/13/2015 1:49 PM, CraigDillabaugh wrote: On Monday, 13 April 2015 at 20:45:29 UTC, weaselcat wrote: I rather liked the anthropomorphized D that used to be somewhere on the site. This guy : http://dlang.org/overview.html I drew that on an envelope many years ago, and scanned it in. My only foray into cartooning :-)
Re: Programming languages and performance
On 4/13/2015 4:28 PM, Walter Bright wrote: https://www.reddit.com/r/programming/comments/32f4as/why_most_high_level_languages_are_slow/ Good article, discussion is a bit lame. One of the reasons I've been range-ifying Phobos is not only to remove dependence on the GC, but often to eliminate allocations entirely, by removing the need for temporaries to hold intermediate results. https://github.com/D-Programming-Language/phobos/pull/3187 https://github.com/D-Programming-Language/phobos/pull/3185 https://github.com/D-Programming-Language/phobos/pull/3179 https://github.com/D-Programming-Language/phobos/pull/3178 https://github.com/D-Programming-Language/phobos/pull/3167
Re: IMAP library
On Monday, 13 April 2015 at 18:03:12 UTC, Jens Bauer wrote: On Monday, 13 April 2015 at 14:31:56 UTC, Johannes Pfau wrote: Am Sun, 12 Apr 2015 17:27:31 + schrieb Jens Bauer doc...@who.no: I won't say it's impossible, but it would be cumbersome processing email on an AVR. There are HTTP servers for AVR(8bit) devices, so it should be possible. That's absolutely true, but usually they're very simple. You can interface the AVR to an external SRAM or NOR-flash and thus store the entire email (or Web-page) there. But imagine that someone sends an email with an attachment - or just writes 50K of babbling. -That might be difficult if you have an AVR with only 8K RAM. It's much easier - and perhaps cheaper - to pick a Cortex-M, which has most of the things you need already; you can get ethernet PHYs for less than $2, which interfaces with a Cortex-M. I am reminded of the constraints from these days: http://www.abook.ru/dmk/FidoNet/unpublished/fhist.html My first 'open source' contribution was to a data structure in his BBS system a few years later.
[Issue 14444] New: Segfault in GC.malloc
https://issues.dlang.org/show_bug.cgi?id=1
Issue ID: 1
Summary: Segfault in GC.malloc
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: mkline.o...@gmail.com
I'm working with a coworker on a small utility that involves building an HTML
report of differences in ELF files. We are accomplishing this in part with ddmp
(https://github.com/francais01/ddmp). Suffice to say that lots of dynamic
arrays are involved.
I was doing some minor refactoring and changed something that looked like
foreach (line; aPipe.byLine) {
// Several line.idup calls to get strings
}
to the more efficient
foreach (line; aPipe.byLineCopy) {
// No more need for .idup to get strings
}
Much to my dismay, the program started segfaulting. I fired up GDB and got the
following trace:
Program received signal SIGSEGV, Segmentation fault.
0x77459e7e in __memset_avx2 () from /usr/lib/libc.so.6
(gdb) where
#0 0x77459e7e in __memset_avx2 () from /usr/lib/libc.so.6
#1 0x005d3ef9 in gc.gc.GC.malloc(ulong, uint, ulong*, const(TypeInfo))
(this=0x8568a0 gc.proxy._gc, ti=0x82aa70 TypeInfo_AS4ddmp4diff4Diff.init$,
alloc_size=0x7fffcb90, bits=8, size=82673) at src/gc/gc.d:459
#2 0x005a671d in gc_qalloc (__HID12=0x7fffcbf8, sz=82673, ba=8,
ti=0x82aa70 TypeInfo_AS4ddmp4diff4Diff.init$) at src/gc/proxy.d:196
#3 0x005a4d2f in core.memory.GC.qalloc(ulong, uint, const(TypeInfo))
(__HID2=0x7fffcc68, ti=0x82aa70 TypeInfo_AS4ddmp4diff4Diff.init$, ba=8,
sz=82673) at src/core/memory.d:368
#4 0x005dbc78 in rt.lifetime.__arrayAlloc(ulong, const(TypeInfo),
const(TypeInfo)) (__HID15=0x7fffcd20, tinext=0x82a9e0
TypeInfo_S4ddmp4diff4Diff.init$, ti=0x82aa70
TypeInfo_AS4ddmp4diff4Diff.init$, arrsize=82656)
at src/rt/lifetime.d:441
#5 0x005aaec5 in _d_arraycatnTX (ti=0x82aa70
TypeInfo_AS4ddmp4diff4Diff.init$, arrs=...) at src/rt/lifetime.d:2206
#6 0x00597b20 in ddmp.util.insert!(ddmp.diff.Diff).insert(ref
ddmp.diff.Diff[], long, ddmp.diff.Diff[]) (stuff=..., i=2821,
array=0x7fffd1d0) at ddmp/source/ddmp/util.d:47
...
The code in frame 6 is just a simple concatenation of a dynamic array and two
slices of another:
void insert(T)( ref T[] array, long i, T[] stuff)
{
assert(i = array.length);
array = array[0..i] ~ stuff ~ array[i..$];
}
I started digging into the garbage collector, but somewhat unsurprisingly, it
is a complex and stateful beast, so I wasn't able to make much headway in the
limited time I have at work. You'll notice the segfault takes place on the
memset in GC.malloc, so one could only assume that the garbage collector thinks
it has some memory it doesn't and blows up when trying to write over it.
Attempts to learn more using valgrind were hampered by lots of alerts coming
from the GC such as small invalid reads and conditional jumps or moves
depending on uninitialized variables. (This is also concerning.)
If there is some way I can produce a dump of the GC heap or any other useful
data, please let me know.
We're on dmd 2.067 using different flavors of Linux (Arch and OpenSUSE 13.2),
FWIW.
--
Re: Programming languages and performance
On Tuesday, 14 April 2015 at 02:44:15 UTC, Laeeth Isharc wrote: thanks for the links and colour, Walter and HST But at the end of the day, the programmer has to know how to write cache-efficient code. No matter how the language/compiler tries to be smart and do the Right Thing(tm), poorly-laid out data is poorly-laid out data, and you're gonna incur cache misses all over the place. Cache-unfriendly algorithms are cache-unfriendly algorithms, and no smart language design / smart optimizer is gonna fix that for you. You have to know how to work with the modern cache hierarchies, how to lay out data for efficient access, and how to write cache-friendly algorithms. While Phobos is making good progress at being allocation-free, it still has a ways to go. And it doesn't help that the current D GC isn't that great, when you do have to allocate -- I've managed to get 30-40% performance improvements just by turning off the default collection schedule and triggering collections myself at more strategic intervals. Would love to see an article sometime on efficient programming in D - both cache efficiency and how to make the GC your friend. (I get the basic idea of data driven design, but not yet the subtleties of cache efficient code and I am sure many other newcomers to D must be in a similar position). I found the same thing as you describe with a monster CSV import (files are daily, but data needs to be organized by symbol to be useful). Not having to box things is a big win IMO, though. Boxing of POD types in Java/C# just screams inefficient to me... can you imagine all that extra, needless indirection wreaking havoc on the CPU cache and cache predictions? There was an interesting post on Lambda the ultimate by Mike Pall (sp? The Lua guy) in which he said certain eyesight DESIGN not eyesight. Ipad spell check. decisions in Python meant much harder to ever make Python fast, and one of the pypy guys agreed with him. (It was more than just boxing). I am not in favour of extrapolating trends mindlessly, but I wonder what the world looks like In five or ten years should the gap between processor perf and memory latency continue to widen at similar rates given continued growth in data set sizes. Laeeth.
Re: IMAP library
On Tuesday, 14 April 2015 at 02:31:23 UTC, Adam D. Ruppe wrote: You might like my email.d too https://github.com/adamdruppe/arsd/blob/master/email.d It is able to help construct emails and also read an mbox format - part of that code might help your imap library too. Thanks, Adam. Was just thinking earlier today that I should reread that code. Laeeth
Re: Programming languages and performance
On Tuesday, 14 April 2015 at 02:39:40 UTC, Walter Bright wrote: On 4/13/2015 7:23 PM, weaselcat wrote: this is essentially fusion/deforestation, correct? ?? http://en.wikipedia.org/wiki/Deforestation_(computer_science)
Re: Programming languages and performance
On Tuesday, 14 April 2015 at 02:45:37 UTC, weaselcat wrote: On Tuesday, 14 April 2015 at 02:39:40 UTC, Walter Bright wrote: On 4/13/2015 7:23 PM, weaselcat wrote: this is essentially fusion/deforestation, correct? ?? http://en.wikipedia.org/wiki/Deforestation_(computer_science) my bad, accidentally hit send there's an example of it on stackoverflow http://stackoverflow.com/questions/578063/what-is-haskells-stream-fusion
Re: Probably you can run a D command line app on an android ARM device
On Monday, 13 April 2015 at 18:30:16 UTC, Johannes Pfau wrote: Am Mon, 13 Apr 2015 17:44:41 + schrieb Laeeth Isharc laeeth.nos...@nospam-laeeth.com: On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote: On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote: BTW - since we have linux on ARM, the following may be useful if you wish to run a D application on your Android mobile device. No ADB or root required. http://kevinboone.net/android_nonroot.html I stumbled across that site sometime back when looking for a way to open a shell with my own command-line apps on my Android tablet and run the druntime/phobos unit tests from the command line on an unrooted Android/ARM device. However, that setup is not going to fix the TLS issue that's holding up Android/ARM. D sticks all non-shared/__gshared globals in Thread-Local Storage (TLS) by default, but Android doesn't support TLS natively, so you can't just compile a D app for linux/ARM and run it on Android/ARM, whether with that setup or not. So that is why vibed demo app doesn't work although it does compile. (The TLS kludge not yet in GDC). So if I make all globall gshared, I can do useful work today using Gdc on arm android, even if I have to use an alternative to vibed for the network stuff ? I didn't read all of this discussion. Does the chroot method mean you can use glibc? Yes - I think so. Otherwise I presume the standard ARM arch distribution (which is running on my phone under the open source project Linux Deploy wouldn't work. I don't know what dark magic, if any, is done to make this project function more generally. Anyway, I recently pushed GC support for GCC emulated TLS to GDC which should work just fine on bionic or glibc. However, the GC doesn't work with bionic because of other issues. So your best bet is to build an ARM GDC-compiler with --disable-tls. This way you at least get emulated TLS which should work. Thank you for this. I will give it a try.
Re: Mitigating the attribute proliferation - attribute inference for functions
Freeing D users from the burden of writing redundant attributes that the compiler can infer would be a fantastic enhancement imo. For public functions I was thinking of a way to make inference safer: generating a .di file with the inferred attributes and auto substituted by the return type, and then make the compiler check the inferred attributes against the previous ones and trigger an error if there was an API breakage, forcing the programmer to acknowledge it by removing the function from the .di file, or by fixing the function to match its previous signature. Would this make inference safe enough for public functions?
[Issue 12697] -inline ICE backend\el.c 802
https://issues.dlang.org/show_bug.cgi?id=12697 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz --- Comment #1 from Martin Krejcirik m...@krej.cz --- This now gives error (with -inline only): Error: true (enum string defIdx = default; ) is not an lvalue --
[Issue 14445] New: std.net.curl not usable in @safe code
https://issues.dlang.org/show_bug.cgi?id=14445
Issue ID: 14445
Summary: std.net.curl not usable in @safe code
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bra...@puremagic.com
module safecurl;
void main() @safe
{
import std.net.curl;
import std.stdio: writeln;
char[] foo = get(http://dlang.org/;);
writeln(length: , foo.length);
}
safe-curl.d(8): Error: safe function 'D main' cannot call system function
'std.net.curl.get!(AutoProtocol, char).get'
The rest of std.net.curl is pretty much the same.. the whole module needs to be
whacked by the @safe stick.
--
Re: DMD 64 bit on Windows
Main article here: http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
[Issue 14446] New: ICE on invalid import
https://issues.dlang.org/show_bug.cgi?id=14446
Issue ID: 14446
Summary: ICE on invalid import
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ket...@ketmar.no-ip.org
dmd ices with the following command line:
dmd -c -o- tinycdb.d tinycdbmk.d
=== tinycdb.d ===
module iv;
struct CDB {}
=== tinycdbmk.d ===
struct CDBMaker {
import tinycdb;
}
--
DMD 64 bit on Windows
I'm currently experiencing Out Of Memory errors when compiling in DMD on Windows Has anyone found a way to compile a DMD x86_64 compiler on Windows?
Re: DMD 64 bit on Windows
On Tuesday, 14 April 2015 at 01:31:27 UTC, Etienne wrote: I'm currently experiencing Out Of Memory errors when compiling in DMD on Windows Has anyone found a way to compile a DMD x86_64 compiler on Windows? For example, here: https://translate.google.ru/translate?hl=rusl=rutl=enu=http%3A%2F%2Fblogsoftware.ru%2Fpost%2F116109292742%2F64-x-dmd
Re: I came up with a new logo for the D language
On 4/13/2015 9:42 AM, bitwise wrote: The next biggest things on my wish list are actually delivering on the optional GC promise https://github.com/D-Programming-Language/phobos/pull/3187 https://github.com/D-Programming-Language/phobos/pull/3185 https://github.com/D-Programming-Language/phobos/pull/3179 https://github.com/D-Programming-Language/phobos/pull/3178 https://github.com/D-Programming-Language/phobos/pull/3167
Re: DMD 64 bit on Windows
On 4/13/2015 9:42 PM, Dennis Ritchie wrote: Main article here: http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29 I think this might be about the -m64 option in the d compiler. I'm actually having the Out Of Memory error with the -m64 option, because DMD crashes at 4gb of ram What I need is DMD compiled with 64 bit pointer size
Re: IMAP library
You might like my email.d too https://github.com/adamdruppe/arsd/blob/master/email.d It is able to help construct emails and also read an mbox format - part of that code might help your imap library too.
Re: Programming languages and performance
On 4/13/2015 7:23 PM, weaselcat wrote: this is essentially fusion/deforestation, correct? ??
[Issue 12891] add atomicFetchAdd and atomicFetchSub to core.atomic
https://issues.dlang.org/show_bug.cgi?id=12891 --- Comment #12 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/c5f10192bb88255beec572bfc2e3510267ecd766 Merge pull request #1208 from jadbox/fetchmod fix Issue 12891: add atomicFetchAdd to core.atomic --
[Issue 14435] [D1] backport deprecated(msg)
https://issues.dlang.org/show_bug.cgi?id=14435 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14435] [D1] backport deprecated(msg)
https://issues.dlang.org/show_bug.cgi?id=14435
--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/bc99930d1c92f997c849e5925f9f17455c7b2470
fix Issue 14435 - [D1] backport deprecated('msg')
--
Re: std.reflection prototype
On Mon, 13 Apr 2015 08:57:26 -0400, rcorre r...@rcorre.net wrote:
For me, having a solid reflection library like this is one of the most
important improvements D can make right now.
At this point, I've kinda hit a wall.
Generating a hierarchical/object-oriented representation of the type
system at compile-time using templates seems to be an all-or-nothing
procedure.
Below is an example of the base() method of ClassRefl:
const(ClassRefl) base() const {
static if(!is(T == Object)) {
alias BaseClassesTuple!T base_type;
return reflect!(base_type[0]);
}
}
The method returns reflect!(base_type[0]), which, when instantiated,
will create another ClassRefl for the base class. That ClassRefl will also
have a base() method, which will instantiate more reflections/templates,
and so on... I also had a parent() method at one point, but since a module
can be the parent of a class, it was possible that reflecting a single
class using reflect!T could build entire reflection hierarchies for
several modules. As soon as you reflect anything right now, all dependent
reflections must also be instantiated. The amount of bloat(compiled binary
size), and the increase in compile time would most likely be a deal
breaker for a lot of people. My approach could probably be optimized, but
I'm not sure it would be enough to make it usable.
I'm out of ideas right now, but open to suggestions if you have a solution
to the above problem.
How can you get the static type of a reflected field? For example:
alias T = reflect!Foo.fields[0].field_type
doSomethingWithType!T
I don't believe an answer exists with my current design.
How can you get the user-defined attributes of a given ScopeRefl?
I don't think this is possible either with the current design. The current
design must also work at runtime, and since UDAs can be any symbol, I'm
not sure there is a good way to generalize this. I could wrap all
attributes in an AttributeRefl class, but there wouldn't be much to tell
about the wrapped attribute beside it's type, and maybe a string
representation of it(more bloat).
I'm sure that more could be done to complement __traits and std.traits,
but I don't think that includes using my reflection library in it's
current state.
I can say that the techniques I used in jsonizer got pretty hacky --
there's a whole lot of __traits and one monstrous
mixin template.
You may want to look at Orange.
https://github.com/jacob-carlborg/orange
The API is clean, and non-invasive. The only downside for me, is that in
order to serialize a class by a base pointer, you have to register it at
compile time.
If I understand correctly, more work needs to be done in druntime to
better support reflection, but I've read this thread about 3 times and
I'm still having a hard time figuring out whats going on :)
The RTInfo(T) template would, in theory, automatically generate some
custom metadata for every type. The compiler automatically instantiates
the RTInfo(T) template for each type right now. The idea was suggested
that a programmer could create their own RTInfo(T) that the compiler would
use that instead. This option was thrown out because it doesn't work with
separate compilation. Right now, RTInfo(T) is defined in object.d, which
is implicitly imported into every module that you compile, but if you had
your own RTInfo defined in your own module, it wouldn't be available to
any other modules at compile time, nor would it be available to any third
party libraries you may be using.
The OffsetTypeInfo thing would be compiler generated. However, the oldest
version of DMD I can find on github (2009) says this:
// offTi[]
dtdword(dt, 0);
dtdword(dt, 0);// null for now, fix later
So I'm not sure why it was never implemented. I may eventually attempt a
pull request for the above fix.
For the most part, this looks really nice. Thanks for putting it
together, bitwise!
Thanks ;)
[Issue 14447] adding isRandomAccessRange!S causes std.array unittests to fail to compile
https://issues.dlang.org/show_bug.cgi?id=14447 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=8521 --
Re: Probably you can run a D command line app on an android ARM device
On Monday, 13 April 2015 at 17:44:42 UTC, Laeeth Isharc wrote: On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote: So that is why vibed demo app doesn't work although it does compile. (The TLS kludge not yet in GDC). So if I make all globall gshared, I can do useful work today using Gdc on arm android, even if I have to use an alternative to vibed for the network stuff ? Yes, but that is harder than it sounds, because often those globals are supposed to be thread-local. Dan Olson has a branch of druntime for iOS where he uses pthreads instead for TLS, for the handful of places where druntime needs it: https://github.com/smolt/druntime/blob/ios/src/ldc/xyzzy.d#L83 Phobos uses TLS globals much more, so it's prohibitive to do the same there. That means you could use druntime but not phobos if you wanted to go this route, as I mentioned to Rishub earlier in this thread. The alternative is to run a full linux install in a chroot: https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy But that requires root, so you're back to square one. Well, I have root. But if I get somebody else to start playing with my app, I don't want to have to make them root their device just to see what it does. Yep, one of the many problems with root. On Monday, 13 April 2015 at 18:30:16 UTC, Johannes Pfau wrote: I didn't read all of this discussion. Does the chroot method mean you can use glibc? Yes, I believe so.
[Issue 14447] New: adding isRandomAccessRange!S causes std.array unittests to fail to compile
https://issues.dlang.org/show_bug.cgi?id=14447 Issue ID: 14447 Summary: adding isRandomAccessRange!S causes std.array unittests to fail to compile Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com This bug happens in compiling Phobos unittests. To reproduce: 1. edit std\utf.d and add the lines: pragma(msg, S); pragma(msg, isRandomAccessRange!S); after the lines in the wchar overload of decodeImpl() that say: //@@@BUG@@@ 8521 forces this to be done outside of decodeImpl //enum canIndex = is(S : const wchar[]) || (isRandomAccessRange!S hasSlicing!S hasLength!S); 2. compile std\array.d for unittests with: dmd std\array -main -unittest and you'll be greeted with: dmd std\array -unittest -main wchar[] false wstring false std\array.d(1543): Error: template std.array.split cannot deduce function from argument types !()(wstring, string), candidates are: std\array.d(1402):std.array.split(S)(S s) if (isSomeString!S) std\array.d(1508):std.array.split(Range, Separator)(Range range, Separator sep) if (isForwardRange!Range is(typeof(ElementType!Range.init == Separator.init))) std\array.d(1515):std.array.split(Range, Separator)(Range range, Separator sep) if (isForwardRange!Range isForwardRange!Separator is(typeof(ElementType!Range.init == ElementType!Separator.init))) std\array.d(1522):std.array.split(alias isTerminator, Range)(Range range) if (isForwardRange!Range is(typeof(unaryFun!isTerminator(range.front Tested on Windows. Probably related to https://issues.dlang.org/show_bug.cgi?id=8521, but I made it a separate issue because this does not present with an ICE. --
[Issue 8521] ICE(e2ir.c) when a function uses a template which relies on that function and -release and -inline are used
https://issues.dlang.org/show_bug.cgi?id=8521 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|RESOLVED|REOPENED See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14447 Resolution|WORKSFORME |--- --
Re: Programming languages and performance
On Tuesday, 14 April 2015 at 02:23:08 UTC, weaselcat wrote: On Tuesday, 14 April 2015 at 02:12:18 UTC, Walter Bright wrote: On 4/13/2015 4:28 PM, Walter Bright wrote: https://www.reddit.com/r/programming/comments/32f4as/why_most_high_level_languages_are_slow/ Good article, discussion is a bit lame. One of the reasons I've been range-ifying Phobos is not only to remove dependence on the GC, but often to eliminate allocations entirely, by removing the need for temporaries to hold intermediate results. this is essentially fusion/deforestation, correct? No. That would be to take two call chains and merge them into one. That's difficult to achieve when you have memory barriers.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:51:27 UTC, Ola Fosheim Grøstad wrote: On Monday, 13 April 2015 at 17:24:38 UTC, Steven Schveighoffer wrote: Note, it's best to show when comparing C/C++ to D the C++ code and how you expect it to work too. Did you compile C++ with strict/pedantic options? ( I don't think it should work in compliant C++ ) Dunno about C++, but IIRC VLAs are part of the C99 standard.
Re: DlangUI
On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote:
Hello!
I would like to announce my project, DlangUI library -
cross-platform GUI for D.
https://github.com/buggins/dlangui
License: Boost License 1.0
Native library written in D (not a wrapper to other GUI
library) - easy to extend.
As a backend, uses SDL2 on any platform, Win32 API on Windows,
XCB on Linux. Other backends can be added easy.
Tested on Windows and Linux.
Supports hardware acceleration - drawing using OpenGL when
built with version=USE_OPENGL.
Unicode support.
Internationalization support.
Uses Win32 API fonts on Windows, and FreeType on other
platforms.
Same look and feel can be achieved on all platforms.
Flexible look and feel - themes and styles.
API is a bit similar to Android UI.
Flexible layout, support of different screen DPI, scaling.
Uses two phase layout like in Android.
Supports drawable resources in .png and .jpeg, nine-patch pngs
and state drawables like in Android.
Single threaded. Use other threads for performing slow tasks.
Mouse oriented.
Actually, it's a port (with major redesign) of my library used
for cross-platform version of my application CoolReader from
C++.
State of project: alpha. But, already can be used for simple 2D
games and simple GUI apps.
I'm keeping in mind a goal to write D language IDE based on
dlangui. :)
Adding support of 3D graphics is planned.
Currently implemented widgets:
TextWidget - simple static text (TODO: implement multiline
formatting)
ImageWidget - static image
Button - simple button with text label
ImageButton - image only button
TextImageButton - button with icon and label
CheckBox - check button with label
RadioButton - radio button with label
EditLine - single line edit
EditBox - multiline editor
VSpacer - vertical spacer - just an empty widget with
layoutHeight == FILL_PARENT, to fill vertical space in layouts
HSpacer - horizontal spacer - just an empty widget with
layoutWidth == FILL_PARENT, to fill horizontal space in layouts
ScrollBar - scroll bar
TabControl - tabs widget, allows to select one of tabs
TabHost - container for pages controlled by TabControl
TabWidget - combination of TabControl and TabHost
Layouts - Similar to layouts in Android
LinearLayout - layout children horizontally or vertically
depending on orientation
VerticalLayout - just a LinearLayout with vertical orientation
HorizontalLayout - just a LinearLayout with vertical orientation
FrameLayout - all children occupy the same place; usually onle
one of them is visible
TableLayout - children are aligned into rows and columns of
table
List Views - similar to lists in Android UI API.
ListWidget - layout dynamic items horizontally or vertically
(one in row/column) with automatic scrollbar; can reuse widgets
for similar items
ListAdapter - interface to provide data and widgets for
ListWidget
WidgetListAdapter - simple implementation of ListAdapter
interface - just a list of widgets (one per list item) to show
Sample project, example1 contains demo code for most of dlangui
API.
Try it using DUB:
git clone https://github.com/buggins/dlangui.git
cd dlangui
dub run dlangui:example1
Fonts note: on Linux, several .TTFs are loaded from hardcoded
paths (suitable for Ubuntu).
TODO: add fontconfig support to access all available system
fonts.
Helloworld:
// main.d
import dlangui.all;
mixin DLANGUI_ENTRY_POINT;
/// entry point for dlangui based application
extern (C) int UIAppMain(string[] args) {
// resource directory search paths
string[] resourceDirs = [
appendPath(exePath, ../res/), // for Visual D and
DUB builds
appendPath(exePath, ../../res/) // for Mono-D builds
];
// setup resource directories - will use only existing
directories
Platform.instance.resourceDirs = resourceDirs;
// select translation file - for english language
Platform.instance.uiLanguage = en;
// load theme from file theme_default.xml
Platform.instance.uiTheme = theme_default;
// create window
Window window = Platform.instance.createWindow(My Window,
null);
// create some widget to show in window
window.mainWidget = (new Button()).text(Hello
worldd).textColor(0xFF); // red text
// show window
window.show();
// run message loop
return Platform.instance.enterMessageLoop();
}
DDOC generated documentation can be found there:
https://github.com/buggins/dlangui/tree/master/docs
For more info see readme and example1 code.
I would be glad to see any feedback.
Can this project be useful for someone? What features/widgets
are must have for you?
Best regards,
Vadim coolreader@gmail.com
Is there any way I can debug a unittest build? Start Debugging
seems bound to the debug build.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:24:38 UTC, Steven Schveighoffer wrote: Note, it's best to show when comparing C/C++ to D the C++ code and how you expect it to work too. Did you compile C++ with strict/pedantic options? ( I don't think it should work in compliant C++ )
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:02:13 UTC, CraigDillabaugh wrote:
On Monday, 13 April 2015 at 16:53:55 UTC, BS LD wrote:
As you know in 'C' you can create a variable-length-array
using variably modified type and a run-time variable
allocating a storage for it - the same way for any local
(normally using the stack).
However in 'D' I don't see such feature. Code like this fails:
void main()
{
size_t szArr = 3;
int[szArr] arr;
}
With this error message:
error: variable szArr cannot be read at compile time
int[szArr] arr;
Life example -
http://melpon.org/wandbox/permlink/a6CzBhYk88FohKlf
Note: I'm also amazed why 'D' compiler can't detect that
'szArr' is a constant anyway.
This likely belongs in D.learn. What you are looking for is:
int[] arr;
arr.length = 3;
I suppose this will allocate the array on the 'heap' or it's
storage will last past the function scope doesn't it?
What I want is to allocate such variable-length-array on the
stack as any other local variable.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:05:59 UTC, BS LD wrote:
On Monday, 13 April 2015 at 17:02:13 UTC, CraigDillabaugh wrote:
On Monday, 13 April 2015 at 16:53:55 UTC, BS LD wrote:
As you know in 'C' you can create a variable-length-array
using variably modified type and a run-time variable
allocating a storage for it - the same way for any local
(normally using the stack).
However in 'D' I don't see such feature. Code like this fails:
void main()
{
size_t szArr = 3;
int[szArr] arr;
}
With this error message:
error: variable szArr cannot be read at compile time
int[szArr] arr;
Life example -
http://melpon.org/wandbox/permlink/a6CzBhYk88FohKlf
Note: I'm also amazed why 'D' compiler can't detect that
'szArr' is a constant anyway.
This likely belongs in D.learn. What you are looking for is:
int[] arr;
arr.length = 3;
I suppose this will allocate the array on the 'heap' or it's
storage will last past the function scope doesn't it?
What I want is to allocate such variable-length-array on the
stack as any other local variable.
Yes, and as John pointed out it isn't the nicest way to do this.
Sorry for the noise.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:05:59 UTC, BS LD wrote:
On Monday, 13 April 2015 at 17:02:13 UTC, CraigDillabaugh wrote:
On Monday, 13 April 2015 at 16:53:55 UTC, BS LD wrote:
As you know in 'C' you can create a variable-length-array
using variably modified type and a run-time variable
allocating a storage for it - the same way for any local
(normally using the stack).
However in 'D' I don't see such feature. Code like this fails:
void main()
{
size_t szArr = 3;
int[szArr] arr;
}
With this error message:
error: variable szArr cannot be read at compile time
int[szArr] arr;
Life example -
http://melpon.org/wandbox/permlink/a6CzBhYk88FohKlf
Note: I'm also amazed why 'D' compiler can't detect that
'szArr' is a constant anyway.
This likely belongs in D.learn. What you are looking for is:
int[] arr;
arr.length = 3;
I suppose this will allocate the array on the 'heap' or it's
storage will last past the function scope doesn't it?
What I want is to allocate such variable-length-array on the
stack as any other local variable.
I suppose alloca will do it (somewhat unsafe?).
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:08:57 UTC, CraigDillabaugh wrote:
On Monday, 13 April 2015 at 17:05:59 UTC, BS LD wrote:
On Monday, 13 April 2015 at 17:02:13 UTC, CraigDillabaugh
wrote:
On Monday, 13 April 2015 at 16:53:55 UTC, BS LD wrote:
As you know in 'C' you can create a variable-length-array
using variably modified type and a run-time variable
allocating a storage for it - the same way for any local
(normally using the stack).
However in 'D' I don't see such feature. Code like this
fails:
void main()
{
size_t szArr = 3;
int[szArr] arr;
}
With this error message:
error: variable szArr cannot be read at compile time
int[szArr] arr;
Life example -
http://melpon.org/wandbox/permlink/a6CzBhYk88FohKlf
Note: I'm also amazed why 'D' compiler can't detect that
'szArr' is a constant anyway.
This likely belongs in D.learn. What you are looking for is:
int[] arr;
arr.length = 3;
I suppose this will allocate the array on the 'heap' or it's
storage will last past the function scope doesn't it?
What I want is to allocate such variable-length-array on the
stack as any other local variable.
Yes, and as John pointed out it isn't the nicest way to do
this. Sorry for the noise.
I should mention that while it is on the heap, the storage should
get GC'd.
Re: I came up with a new logo for the D language
On Monday, 13 April 2015 at 10:31:06 UTC, ixid wrote: On Monday, 13 April 2015 at 07:12:29 UTC, deadalnix wrote: It does not matter if one knows this is planets or not (these aren't planet technically, but phobos and deimos, mars's moons). What does matter is that the logo is recognized and associated with D. Any logo change goes against that goal, so that's probably won't happen. Do you think anyone outside a tiny number of forum users would recognize the logo at this stage? Yes. I'm fairly confident that more people know about the D logo than D itself.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:05:59 UTC, BS LD wrote:
On Monday, 13 April 2015 at 17:02:13 UTC, CraigDillabaugh wrote:
On Monday, 13 April 2015 at 16:53:55 UTC, BS LD wrote:
As you know in 'C' you can create a variable-length-array
using variably modified type and a run-time variable
allocating a storage for it - the same way for any local
(normally using the stack).
However in 'D' I don't see such feature. Code like this fails:
void main()
{
size_t szArr = 3;
int[szArr] arr;
}
With this error message:
error: variable szArr cannot be read at compile time
int[szArr] arr;
Life example -
http://melpon.org/wandbox/permlink/a6CzBhYk88FohKlf
Note: I'm also amazed why 'D' compiler can't detect that
'szArr' is a constant anyway.
It can, but allowing any variable that happens to be determined
at compile-time to be used by other compile-time constructs just
doesn't scale, especially with D's extensive meta-programming
abilities.
int[] arr;
arr.length = 3;
I suppose this will allocate the array on the 'heap' or it's
storage will last past the function scope doesn't it?
What I want is to allocate such variable-length-array on the
stack as any other local variable.
You can use alloca to get this effect:
import core.stdc.stdlib: alloca;
void main()
{
int s = 4;
auto arr = (cast(float*)alloca(s))[0..s];
arr[] = 5;
assert(arr == [5,5,5,5]);
}
It's not pretty, but it works.
Re: Does 'D' language supports 'C' like VLA?
This should work the way you want it to:
void main()
{
immutable size_t szArr = 3;
int[szArr] arr;
}
Regards,
Dmitri
On Mon, Apr 13, 2015 at 7:05 PM, BS LD via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 13 April 2015 at 17:02:13 UTC, CraigDillabaugh wrote:
On Monday, 13 April 2015 at 16:53:55 UTC, BS LD wrote:
As you know in 'C' you can create a variable-length-array using variably
modified type and a run-time variable allocating a storage for it - the same
way for any local (normally using the stack).
However in 'D' I don't see such feature. Code like this fails:
void main()
{
size_t szArr = 3;
int[szArr] arr;
}
With this error message:
error: variable szArr cannot be read at compile time
int[szArr] arr;
Life example - http://melpon.org/wandbox/permlink/a6CzBhYk88FohKlf
Note: I'm also amazed why 'D' compiler can't detect that 'szArr' is a
constant anyway.
This likely belongs in D.learn. What you are looking for is:
int[] arr;
arr.length = 3;
I suppose this will allocate the array on the 'heap' or it's storage will
last past the function scope doesn't it?
What I want is to allocate such variable-length-array on the stack as any
other local variable.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:20:04 UTC, Dmitri Makarov wrote:
This should work the way you want it to:
void main()
{
immutable size_t szArr = 3;
int[szArr] arr;
}
Regards,
Dmitri
No, this isn't what VLA is. Ola Fosheim Grøstad has the right of
it; he'll need to use alloca to dynamically extend the stack.
What OP is referring to is the ability to create a dynamically
sized array on the stack, rather than the heap. Here's a good
description of what VLA is and how it works:
https://en.wikipedia.org/wiki/Variable-length_array
Re: Does 'D' language supports 'C' like VLA?
On 4/13/15 12:53 PM, BS LD wrote:
As you know in 'C' you can create a variable-length-array using variably
modified type and a run-time variable allocating a storage for it - the
same way for any local (normally using the stack).
However in 'D' I don't see such feature. Code like this fails:
void main()
{
size_t szArr = 3;
int[szArr] arr;
}
With this error message:
error: variable szArr cannot be read at compile time
int[szArr] arr;
Life example - http://melpon.org/wandbox/permlink/a6CzBhYk88FohKlf
Note, it's best to show when comparing C/C++ to D the C++ code and how
you expect it to work too.
I experimented a bit with C++ to see what it will do:
#include stdio.h
int main(int argc, char *argv[])
{
int arr[argc];
int i;
printf(i: %p, arr[0]: %p\n, i, arr[0]);
}
Which makes the array completely variable size depending on argc (a
runtime variable). The results surprised me a bit:
$ ./testvararray
i: 0x7fff5aeadb5c, arr[0]: 0x7fff5aeadb30
$ ./testvararray a
i: 0x7fff5a955b4c, arr[0]: 0x7fff5a955b20
$ ./testvararray a b
i: 0x7fff5854eb4c, arr[0]: 0x7fff5854eb20
$ ./testvararray a b c
i: 0x7fff5fb12b3c, arr[0]: 0x7fff5fb12b10
$ ./testvararray a b c d
i: 0x7fff528e1b2c, arr[0]: 0x7fff528e1af0
So the code will move i around depending on arr size. It's consistent
between runs as well, if you pass the same number of args. I didn't
expect that, but I wasn't sure exactly what I expected :)
D doesn't do this, you have to know the size of the stack array at
compile time. You can use alloca, which will give you some runtime
allocation of stack, but it can be dangerous (as noted).
Note: I'm also amazed why 'D' compiler can't detect that 'szArr' is a
constant anyway.
Value range propagation (the compiler understanding what values a
variable can be at some point in time) only is inside one statement. It
does not remember what szArr can be at a later statement.
-Steve
Re: D vs nim
I think people interested in D should take a closer look at nim and judge for yourself ; http://nim-lang.org/tut1.html is a good starting point (docs in general are very well written). I went through their tutorials and here are some first impressions: * nim is already bootstrapped (self-compiles) * feature set is very rich, many features (semantic and syntax) not found in D or improving the ones in D, eg hygenic macros, * many key features of D (static if, type inference, CTFE, UFCS, lambda, template constraints). * The syntax seems more orthogonal with fewer bultin constructs and many generated by library, eg: 'ab is a hygyenic macro that generates 'ba'; associative arrays (tables) are in library * documentation in code uses markdown (less noisy than D's) * named parameter arguments * tooling (nimble package manager ~dub, nimfix ~= gofix; nimgrep ~= dscanner); * etc... less good or tradeoffs: * C backend instead of (LLVM,gcc or dmd's; but they're working on it * uses yield-based ranges instead of D-based ranges (maybe simpler to write but less efficient?) * forward declarations needed (docs says this may change) * thread-local GC (no stop the world) * RAII still experimental it seems * mutually importing modules seem possible; but doc says: Modules that depend on each other are possible, but strongly discouraged; it's very common in D * mutually recursive types. In Nim these types can only be declared within a single type section. (Anything else would require arbitrary symbol lookahead which slows down compilation.) not sure whether language has those; need to look more in the docs: * delegates * template variadic (but has varargs[T]) * not sure whether we can have template parameters which are other than a type It would be nice to have a wiki page to describe this further feature by feature. Many ideas would be great to incorporate in D too btw. On Fri, Apr 10, 2015 at 2:26 PM, bachmeier via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons. Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use.
Re: I came up with a new logo for the D language
On Monday, 13 April 2015 at 15:12:18 UTC, Gary Willoughby wrote: On Monday, 13 April 2015 at 12:49:19 UTC, Abdulhaq wrote: I'd suggest a fresh look be introduced when the ref counting and GC work has been done, Believe it or not i'm not opposed to this. and personally I'd suggest just a simple clean 2D metro-ish D as the logo, No. This is fashion. Hire a professional to do it and make long term usability a requirement. The 2d flat look will feel very old when the big boys (Microsoft, Apple) move on. I don't think any of the proposed logos have been better than the current one (which also works well as a tiny icon), but you could easily flatten the logo by just keeping the white symbol and put it on a black bar with the menu beneath as part of the current webpage upgrade. You could keep the red by making the tiny circle red. The current image is a little bit overdone and so much red is screaming. Changing the outline of the logo without backing it up with a major language version announcement is rather pointless IMO.
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:24:05 UTC, Dylan Knutson wrote:
On Monday, 13 April 2015 at 17:20:04 UTC, Dmitri Makarov wrote:
This should work the way you want it to:
void main()
{
immutable size_t szArr = 3;
int[szArr] arr;
}
Regards,
Dmitri
No, this isn't what VLA is. Ola Fosheim Grøstad has the right
of it; he'll need to use alloca to dynamically extend the
stack. What OP is referring to is the ability to create a
dynamically sized array on the stack, rather than the heap.
Here's a good description of what VLA is and how it works:
https://en.wikipedia.org/wiki/Variable-length_array
Ah, ok, then why did he complain that the compiler can't
determine that the value of szArr is known at compile-time. A
kind of conundrum, isn't it -- he want's to create arrays on
stack with their sizes known at run-time, but wants the compiler
to figure the size of such an array at compile-time...
Re: Does 'D' language supports 'C' like VLA?
On Monday, 13 April 2015 at 17:24:38 UTC, Steven Schveighoffer
wrote:
On 4/13/15 12:53 PM, BS LD wrote:
As you know in 'C' you can create a variable-length-array
using variably
modified type and a run-time variable allocating a storage for
it - the
same way for any local (normally using the stack).
However in 'D' I don't see such feature. Code like this fails:
void main()
{
size_t szArr = 3;
int[szArr] arr;
}
With this error message:
error: variable szArr cannot be read at compile time
int[szArr] arr;
Life example -
http://melpon.org/wandbox/permlink/a6CzBhYk88FohKlf
Note, it's best to show when comparing C/C++ to D the C++ code
and how you expect it to work too.
I experimented a bit with C++ to see what it will do:
#include stdio.h
int main(int argc, char *argv[])
{
int arr[argc];
int i;
printf(i: %p, arr[0]: %p\n, i, arr[0]);
}
Which makes the array completely variable size depending on
argc (a runtime variable). The results surprised me a bit:
$ ./testvararray
i: 0x7fff5aeadb5c, arr[0]: 0x7fff5aeadb30
$ ./testvararray a
i: 0x7fff5a955b4c, arr[0]: 0x7fff5a955b20
$ ./testvararray a b
i: 0x7fff5854eb4c, arr[0]: 0x7fff5854eb20
$ ./testvararray a b c
i: 0x7fff5fb12b3c, arr[0]: 0x7fff5fb12b10
$ ./testvararray a b c d
i: 0x7fff528e1b2c, arr[0]: 0x7fff528e1af0
So the code will move i around depending on arr size. It's
consistent between runs as well, if you pass the same number of
args. I didn't expect that, but I wasn't sure exactly what I
expected :)
D doesn't do this, you have to know the size of the stack array
at compile time. You can use alloca, which will give you some
runtime allocation of stack, but it can be dangerous (as noted).
I don't know how things are handled here but it will be very nice
if someone could make the language support this.
Note: I'm also amazed why 'D' compiler can't detect that
'szArr' is a
constant anyway.
Value range propagation (the compiler understanding what values
a variable can be at some point in time) only is inside one
statement. It does not remember what szArr can be at a later
statement.
-Steve
Although I think it will be a nice feature if it can. I would
prefer slower compilation then slower code.
[Issue 14442] Wrong this.outer reference in nested classes
https://issues.dlang.org/show_bug.cgi?id=14442 Iain Buclaw ibuc...@gdcproject.org changed: What|Removed |Added Keywords||accepts-invalid, diagnostic CC||ibuc...@gdcproject.org --
[Issue 14442] Wrong this.outer reference in nested classes
https://issues.dlang.org/show_bug.cgi?id=14442
--- Comment #1 from Iain Buclaw ibuc...@gdcproject.org ---
Also affects the debug code written. As all you see of this parent chain is
garbage values.
(gdb) p this
$1 = (__anonclass1 ) @0x77ed5fc0:
{
Object = {
__vptr = 0x4890e0 vtable nested.Foo35.bar().__anonclass1,
__monitor = 0x0
},
this = @0x77ed6ff0// -- closure pointer
}
(gdb) p this.this
$2 = (Foo35 ) @0x77ed6ff0:
{
Object = {
__vptr = 0x77ed5fe0,// -- Foo35 object reference
__monitor = 0x2b// -- 'y' value
},
x = 0// -- Excess garbage
}
--
Re: Probably you can run a D command line app on an android ARM device
On Monday, 13 April 2015 at 06:37:34 UTC, weaselcat wrote: Is there a need for people running tests on Raspberry Pis? I'm planning on picking up the new version in a few days, was unaware D even really worked on ARM. Currently vibe.d uses Travis CI so unless it gets replaced with some self-hosted CI solution I don't think anything can really be done here right now. Well, apart from trying it out and reporting bugs if there are any :)
Re: I came up with a new logo for the D language
It does not matter if one knows this is planets or not (these aren't planet technically, but phobos and deimos, mars's moons). What does matter is that the logo is recognized and associated with D. Any logo change goes against that goal, so that's probably won't happen.
[Issue 14442] Wrong this.outer reference in nested classes
https://issues.dlang.org/show_bug.cgi?id=14442 Dicebot pub...@dicebot.lv changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #2 from Dicebot pub...@dicebot.lv --- Is it effectively another manifestation of have one context pointer, need many issue? --
Re: Mitigating the attribute proliferation - attribute inference for functions
On Monday, 13 April 2015 at 05:52:47 UTC, Dicebot wrote: I think point about `export` is important. Tying definition of API to `export` instead of `public` fits much better definition of those attributes (latter only guarantees symbol access, former also ensures cross-binary availablity) and allows for more explicit migration step (as `export` is widely underused right now). Also the issue you have pointed out about API templates that call private functions is essentially same issue as Benjamin was pointing out here : http://forum.dlang.org/post/m9lhc3$1r1v$1...@digitalmars.com I can't propose good solution here right now but I do believe those 2 problems need to be solved in one step. Although I'd still want to see dust around reference counting DIPs settled first to get a full attention on this matter and avoid commiting to premature solution.
Re: I came up with a new logo for the D language
On Monday, 13 April 2015 at 08:14:05 UTC, Abdulhaq wrote: On Sunday, 12 April 2015 at 22:02:01 UTC, Barry Smith wrote: It's simple, but clean. Somewhat similar to the old one. Hope you like it. http://s2.postimg.org/m6qcfemhl/dlang.png Email me at barry.of.sm...@gmail.com if you want the SVG version. This idea improves on the current one in that it is much clearer that the two 'blobs' are different objects to the D itself. I like it. It's terrible and looks like a student project. Please stop trying to destroy the D brand.
Re: Mixed closures and class.outer references
On 12 April 2015 at 21:36, Iain Buclaw ibuc...@gdcproject.org wrote:
Hi,
Can someone tell me what is supposed to happen in Outer.foo.Inner.bar?
And how it should look in debug?
---
class Outer
{
int x = 42;
void foo()
{
int y = 43;
class Inner
{
void bar()
{
assert(x == 42);
assert(y == 43);
}
}
Inner b = new Inner();
b.bar();
}
}
---
What I'm currently seeing is:
Function: Inner.bar()
Params: (this=...)
typeof(this) == Inner
typeof(this.this) == Outer
No sign of the closure in Outer.foo, so how is 'y' even accessible?
I've raised a bug: https://issues.dlang.org/show_bug.cgi?id=14442
Re: Implementing cent/ucent...
On Tuesday, 7 April 2015 at 15:55:24 UTC, Kai Nacke wrote: Hi all! I started to work on cent/ucent support in LDC (and possible in upstream DMD). Here is the current state: Hurray! I missed that. If you like to help: - clone test - Druntime/Phobos should support cent/ucent. I already updated/created some modules but more work is needed here - add support to the DMD backend I once had added cent/ucent to std/traits.d
Re: This week in D #13: =void tip, ddmd, if(arr) warn, dconf registration
On Monday, 13 April 2015 at 03:37:17 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/apr-12.html http://www.reddit.com/r/d_language/comments/32ek17/this_week_in_d_13_void_tip_ddmd_ifarr_warn_dconf/ https://twitter.com/adamdruppe/status/587459000729473024 The example in the first point of void initialization is wrong: YourStruct s = YourStruct(); With `@disable this()`, this doesn't work either. But this does: YourStruct s = YourStruct.init; About point 3, the following should be added so as not to mislead beginners: This is assignment, not construction! This is an important distinction, because your type's opAssign() and ~this() can then be invoked on an uninitialized object. They need to be aware of that possibility.
