Re: Stack-based @nogc dynamic array
Thank you both for the quick replies. On Thursday, 16 May 2019 at 12:55:34 UTC, Kagamin wrote: Try mach.d https://github.com/pineapplemachine/mach.d it uses explicit range accessors for iteration. Thank you. I've looked into it, and it appears to be quite a big library. I've looked into mach.collect and mach.range, but I didn't manage to find what I was looking for (a simple array data structure). Do you recommend to look into any specific module?
Re: Stack-based @nogc dynamic array
On Thursday, 16 May 2019 at 12:45:03 UTC, Adam D. Ruppe wrote: I think you have overcomplicated something quite simple. int[4] buffer; int bufferLength; buffer[bufferLength++] = item_to_append; buffer[bufferLength++] = item_to_append; int[] slice = buffer[0 .. bufferLength]; // you can use slice to any std.algorithm calls etc // just remember it is on the stack so don't store it beyond a function call Thanks. It's really a lot simpler than I thought. It's slightly error prone (i.e., the code doesn't work if I use ++bufferLength), but its simplicity might be worth the trade-off.
Re: Stack-based @nogc dynamic array
On Thursday, 16 May 2019 at 12:16:26 UTC, Marco de Wild wrote:
Or are there any tips to roll my own implementation?
I took a stab at it:
---
@nogc:
nothrow:
pure:
struct NoGcArray(size_t maxSize, T)
{
private T[maxSize] _buffer;
private T[] _slice;
private size_t _frontIndex;
size_t length() const
{
return _slice.length;
}
void opOpAssign(string op)(T element)
{
static if(op == "~")
{
_buffer[_frontIndex + length] = element;
_slice = _buffer[_frontIndex..(length + 1)];
}
else
{
static assert(false, "Only concatenation supported");
}
}
T opIndex(size_t index) const
{
return _slice[index];
}
T front() const
{
return _slice[0];
}
void popFront()
{
_frontIndex++;
_slice = _slice[1..$];
}
bool empty() const
{
return _slice.length == 0;
}
}
void main()
{
import std.algorithm : sum, map;
NoGcArray!(4, int) array;
array ~= 420;
array ~= 42;
assert(array.map!(x => x*2).sum == 924);
}
---
Mike
Re: Stack-based @nogc dynamic array
On Friday, 17 May 2019 at 06:58:54 UTC, Marco de Wild wrote: Thank you. I've looked into it, and it appears to be quite a big library. I've looked into mach.collect and mach.range, but I didn't manage to find what I was looking for (a simple array data structure). Do you recommend to look into any specific module? You use your array with math.range, but without alias this, it uses explicit accessor `asrange` for iteration.
Blog Post #0036 - File Dialog - Open a Single File
The second post this week continues the series on Dialogs. This one is about opening files and can be found here: http://gtkdcoding.com/2019/05/17/0036-file-open-dialogs.html
Re: Blog Post #0036 - File Dialog - Open a Single File
On Friday, 17 May 2019 at 09:24:59 UTC, Ron Tarrant wrote: The second post this week continues the series on Dialogs. This one is about opening files and can be found here: http://gtkdcoding.com/2019/05/17/0036-file-open-dialogs.html So, I'm using gtkD and eventually I'll have the need to use movable icons that can be interacted with using the icon by dragging them around in a DrawingArea. So if you need ideas to for another tutorial that would be helpful to me. It's probably not too hard but I've not messed with those things yet and maybe you'll find an easier way to deal with it. The idea would be to create DrawingArea and then display the "icons" and have mouse interaction. I'm not sure if using custom drawing or something built in is best. Custom drawing is probably what I'll do since I know more about that then gtk.
Re: Dlang + emscripten
On Thursday, 16 May 2019 at 19:27:15 UTC, Dukc wrote: On Thursday, 16 May 2019 at 18:23:12 UTC, SrMordred wrote: [...] Nice will take a look on this two, thanks :)
Re: Blog Post #0036 - File Dialog - Open a Single File
On Friday, 17 May 2019 at 11:12:41 UTC, Alex wrote: movable icons that can be interacted with using the icon by dragging them around in a DrawingArea. So if you need ideas to for another tutorial... Yup, this type of thing is on my todo list, but my lead time is around six weeks ATM, so it may take a while before it shows up on the blog. Some of the ideas I have for DrawingArea tutorials: - drag-n-drop (as you describe), - nodes-n-noodles (as seen here: https://codepen.io/osublake/pen/4c3752574267b3a986cb8eee7ccb8c81), and (of course) - drawing with the mouse. My plan is to be as thorough as possible with coverage of each widget and to do them in more-or-less easiest to hardest order. Once the series on Dialog windows is finished, there's a whole raft of stuff on ListStore and TreeStore and how they interact with TreeView and ComboBox via TreeIter, TreeSelection, etc., etc. That's taking most of my time ATM. Thanks for the comment, Alex. Have a great day.
Re: Blog Post #0036 - File Dialog - Open a Single File
On 17.05.2019 14:39, Ron Tarrant wrote: On Friday, 17 May 2019 at 11:12:41 UTC, Alex wrote: ListStore and TreeStore and how they interact with TreeView and ComboBox via TreeIter, TreeSelection, etc., etc. That's taking most of my time ATM. That would be really nice! My use case is a large list of TreeView and I failed to make it using Gtk or Qt and start to use immediate mode GUI like dimgui then dear imgui and now nuklear. Also I ported nanogui to D and add a large list widget with different height of items (about 400K) but TreeView widget needs to be implemented. So still I have no a solution that satisfy me completely.
Re: Blog Post #0036 - File Dialog - Open a Single File
On Friday, 17 May 2019 at 12:14:51 UTC, drug wrote: TreeView widget needs to be implemented. So still I have no a solution that satisfy me completely. Yeah, they're confusing, for sure. If you don't need anything elaborate, you might have a look at this: https://github.com/rontarrant/gtkDcoding/blob/master/017_list_tree/list_tree_017_08_columns.d Maybe it'll help.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer [...] hnsecs is more confusing than nanoseconds. People know what a nanosecond is, a hecto-nano-second is not as familiar a term. Agreed, which is why Duration.toString shouldn't be used to present durations to users. Developers, however, are expected to know what a hectonanosecond is, same as with all the other technical terms. "hectonanosecond" looks like an illegal combination of SI prefixes [1]. I recommend changing the meaning of hnsecs to "[one] hundred nanoseconds". [1] "Prefixes may not be used in combination." https://en.wikipedia.org/wiki/Metric_prefix
Re: Framework design, initialization and framework usage
On Monday, 13 May 2019 at 09:25:05 UTC, ztop wrote: [...] The old site is archived in wayback https://web.archive.org/web/20180103191733/http://antigrain.com/ Thanks. That is the page I have been looking for: https://web.archive.org/web/20180306023416/http://www.antigrain.com/research/font_rasterization/index.html
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On 16.05.19 17:55, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote: [...] The output shouldn't involve the inner workings of the type. It should be changed to say 10 ns. If the output is meant for the developer, then I disagree subjectively, as that creates the impression that the lowest resolution or representable unit of time is the nanosecond. If the output is meant for the user, then hectonanoseconds or nanoseconds are going to be almost always irrelevant. The duration should be formatted appropriately to the use case. I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 0.1 µs, right?). No weird "hnsecs", no false precision, still all the data that is there.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Friday, 17 May 2019 at 18:36:00 UTC, ag0aep6g wrote: I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 0.1 µs, right?). No weird "hnsecs", no false precision, still all the data that is there. I was going to propose the same. Hns is weird. Bastiaan.
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Friday, 17 May 2019 at 20:30:56 UTC, Bastiaan Veelo wrote:
On Friday, 17 May 2019 at 18:36:00 UTC, ag0aep6g wrote:
I'd suggest "17 ms, and 553.1µs" for a better default (1 hns
is 0.1 µs, right?). No weird "hnsecs", no false precision,
still all the data that is there.
I was going to propose the same. Hns is weird.
Why not simply 17.5531 ms ("%.4f ms") to get rid of the non-ASCII
µ prefix?
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Friday, 17 May 2019 at 18:02:04 UTC, kdevel wrote: On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev wrote: On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer [...] hnsecs is more confusing than nanoseconds. People know what a nanosecond is, a hecto-nano-second is not as familiar a term. Agreed, which is why Duration.toString shouldn't be used to present durations to users. Developers, however, are expected to know what a hectonanosecond is, same as with all the other technical terms. "hectonanosecond" looks like an illegal combination of SI prefixes [1]. I recommend changing the meaning of hnsecs to "[one] hundred nanoseconds". [1] "Prefixes may not be used in combination." https://en.wikipedia.org/wiki/Metric_prefix It through me off, it really makes no sense. The purpose of a prefix is to define something better. hectonano seems contradictory... and is it any different than nanohecto? There really is no point in it, the whole reason for the metric system is to provide a hierarchical resolution. Just use nano or pico
Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec
On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote: 1 - 17 ms, 553 ╬╝s, and 1 hnsec fancy useless asci hieroglyphic Holy shirt! All that time I was thinking this is just some sort of encoding artifacts in terminal(common problem on windows), especially because IIRC on Linux it is displaying this greek 'micro' correctly. This is completely out of context, and so should be replaced with something more conventional... Now when I realize it, for me it immediately start look like some sort of cave art or graffiti in art gallery, very unprofessional I say.
a way of approximating "API internal" visibility?
I'm working on a library spread across multiple modules/packages. Sometimes I have symbols that I would like to share between internal packages, but I don't want to make 'public' because then it would be exposed to the client-facing API. To a degree this could be gotten around by making things public internally, and then selectively 'public import'-ing individual symbols in the topmost client-facing module (vs. entire packages, as I'm doing now). However I have the following situation for which that won't work: I have a class that's going to be visible to the client, but inside that class I have methods that should only be accessible to other internal packages. So neither 'public' nor 'package' is what I want. I already collapsed one level of what I was doing to get around this issue (putting things in a common package even though I would have preferred they be in separate, sibling packages), but I'm not sure I could do that again without making a mess. Is there some way of approximating an access specifier between 'package' and 'public'? Or am I likely just structuring things very badly to begin with, to even have this problem? I'm not much of a C++ guy but I'd probably resort to using 'friend' to get around this, at least in the case of classes.
Meson build system user learning D.
Hello there this is your hometown Meson build system user here just happen to have a question related to unit testing in D. So is there a way to run the unit-test in the test main as a costume test runner in "test/test.d", and run the executable program in "src/main.d", with this resulting in two executable binaries one for test and one for the program? I was considering using Unity test framework so I would know that if I was running the test runner that it was definitely the custom test runner returning the value of all test cases ran and not a mistake of running the main executable program. But I am not sure if that would insulate the D programming community by not using the provided unit testing functionality in D. I am mostly trying to make a version based on an existing C template but with D language syntax using whatever tools D provides along side Meson build system. I would give you the link(s) but I haven't figured out how to add links here on the D forum, and I just registered. Thanks...
