Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On 11-Jul-2015 00:26, Joakim wrote: On Friday, 10 July 2015 at 20:42:02 UTC, Dmitry Olshansky wrote: On 10-Jul-2015 23:34, Joakim wrote: On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Looks like you have a question on reddit, not sure how he reached that conclusion though: https://www.reddit.com/r/programming/comments/3ck3ru/interview_with_dmitry_olshansky_author_of_ds/ Answered. Never knew it was there at all. Oh, he's probably reacting to these two quotes: "In the end, it turned out that UTF decoding had become the bottleneck and it's soon to be removed." "The key one is to remove decoding of UTF and match directly on the encoded chars" On second thought should have said it like "match directly on encoded characters _as if decoding_ them w/o actually going for decoded code point values". Still confusing I guess. -- Dmitry Olshansky
Re: Voting for std.experimental.allocator
On 11-Jul-2015 01:51, Andrei Alexandrescu wrote: On 7/10/15 4:29 PM, Alex Parrill wrote: On Friday, 10 July 2015 at 18:32:04 UTC, Andrei Alexandrescu wrote: On 7/9/15 5:44 PM, Alex Parrill wrote: Yes, but the mmap allocator on Windows needs to be fixed. What is the issue with it? I recall I pulled something recently. -- Andrei It leaks. http://forum.dlang.org/post/itmcarskypkuospvf...@forum.dlang.org I see. Could you or someone with Windows expertise create a PR for my branch? -- Andrei This one? :) https://github.com/andralex/phobos/pull/17 -- Dmitry Olshansky
Re: Voting for std.experimental.allocator
On 7/10/15 4:29 PM, Alex Parrill wrote: On Friday, 10 July 2015 at 18:32:04 UTC, Andrei Alexandrescu wrote: On 7/9/15 5:44 PM, Alex Parrill wrote: Yes, but the mmap allocator on Windows needs to be fixed. What is the issue with it? I recall I pulled something recently. -- Andrei It leaks. http://forum.dlang.org/post/itmcarskypkuospvf...@forum.dlang.org I see. Could you or someone with Windows expertise create a PR for my branch? -- Andrei
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On Friday, 10 July 2015 at 20:42:02 UTC, Dmitry Olshansky wrote: On 10-Jul-2015 23:34, Joakim wrote: On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Looks like you have a question on reddit, not sure how he reached that conclusion though: https://www.reddit.com/r/programming/comments/3ck3ru/interview_with_dmitry_olshansky_author_of_ds/ Answered. Never knew it was there at all. Oh, he's probably reacting to these two quotes: "In the end, it turned out that UTF decoding had become the bottleneck and it's soon to be removed." "The key one is to remove decoding of UTF and match directly on the encoded chars"
Re: LDC for iOS prebuilt binaries
On Friday, 10 July 2015 at 20:38:16 UTC, Rishub Nagpal wrote: On Thursday, 9 July 2015 at 06:32:28 UTC, Dan Olson wrote: I've made a set of binaries and universal libs for the LDC iOS cross-compiler. It is based on LDC 0.15.1 (2.066) and LLVM 3.5.1. https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.15.1-150708 Only 32-bit devices currently; arm64 work starts next month when I acquire an iPhone 6. The download should have everything needed to run on an OS X build host in the same fashion as LDC downloads. But I may have missed something. Feedback appreciated. Good Work! I'd like to help get D to work on android, but I do not know much about llvm and arm compilers to be of much help. Last I heard there was an issue with exception handling and TLS, is that still so? That's funny, because I was just thinking about putting my Android patches for ldc online and trying to get more people to chip in on working through the remaining tests to be fixed for Android/ARM. I got TLS working a month and a half ago (http://forum.dlang.org/post/imkgasjuvbbasyghd...@forum.dlang.org) and exception-handling seems to be working since this fix I ferreted out last week (http://forum.dlang.org/post/qsfaussopqwwjuljd...@forum.dlang.org). Now it's just codegen issues, with about half of phobos modules' tests failing somewhere, though many of those modules only have a handful of tests that fail. For example, only three unit test blocks fail in std.stdio and one in std.path. Common causes appear to be problems with ranges and functions from std.random. I'm going through each module and commenting out failing tests and checking backtraces, a time-consuming process that's got me thinking about hacking the test runner, so that failing tests in one unit test block won't stop other test blocks from the same module from running, as is the case now. If you or anybody else is interested in chipping in, reply in the Android thread (first link above) and I'll put some patches and build info online. Unfortunately, to really fix any of these issues, you'll probably have to know something about ARM assembly, LLVM IR, and be comfortable stepping through the binary with gdb but without debug info, although simply triaging the tests to figure out what works and what doesn't could probably be done by almost anyone.
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On 10-Jul-2015 23:34, Joakim wrote: On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Looks like you have a question on reddit, not sure how he reached that conclusion though: https://www.reddit.com/r/programming/comments/3ck3ru/interview_with_dmitry_olshansky_author_of_ds/ Answered. Never knew it was there at all. -- Dmitry Olshansky
Re: LDC for iOS prebuilt binaries
On Thursday, 9 July 2015 at 06:32:28 UTC, Dan Olson wrote: I've made a set of binaries and universal libs for the LDC iOS cross-compiler. It is based on LDC 0.15.1 (2.066) and LLVM 3.5.1. https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.15.1-150708 Only 32-bit devices currently; arm64 work starts next month when I acquire an iPhone 6. The download should have everything needed to run on an OS X build host in the same fashion as LDC downloads. But I may have missed something. Feedback appreciated. Good Work! I'd like to help get D to work on android, but I do not know much about llvm and arm compilers to be of much help. Last I heard there was an issue with exception handling and TLS, is that still so? anyway, good job!
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Looks like you have a question on reddit, not sure how he reached that conclusion though: https://www.reddit.com/r/programming/comments/3ck3ru/interview_with_dmitry_olshansky_author_of_ds/
Re: Voting for std.experimental.allocator
On Friday, 10 July 2015 at 18:32:04 UTC, Andrei Alexandrescu wrote: On 7/9/15 5:44 PM, Alex Parrill wrote: Yes, but the mmap allocator on Windows needs to be fixed. What is the issue with it? I recall I pulled something recently. -- Andrei It leaks. http://forum.dlang.org/post/itmcarskypkuospvf...@forum.dlang.org
Re: Last - but not least! - two DConf talks
On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu wrote: Spread the word! https://www.youtube.com/watch?v=bxSPCmwqgYs https://www.youtube.com/watch?v=jNQF3m5e2l0 Andrei Erich's presentation is now my favourite one from this year's DConf. If you read this Erich, I really love your energy! Such nice display is, to me, as important as more technical presentations of D as they touch different people. Thank you!
New ldc2-0.15.2-beta2 Linux suitable for Travis-CI
Hi all! I re-created the Linux binaries. They should now work in Travis-CI again. 2457af89b39d89a237d9bda560c8b5a8 ldc2-0.15.2-beta2-linux-x86.tar.gz b5f1514d52082ac5e6220c23287f799b ldc2-0.15.2-beta2-linux-x86.tar.xz 642ad38c7bf25d8d932e7a00e46c9734 ldc2-0.15.2-beta2-linux-x86_64.tar.gz 18e4d0aec88ebbc58365bdc67b15cc7c ldc2-0.15.2-beta2-linux-x86_64.tar.xz (I did not test this with Travis-CI but I checked that I really statically linked libstdc++.) Regards, Kai
Re: Voting for std.experimental.allocator
On 7/9/15 5:44 PM, Alex Parrill wrote: Yes, but the mmap allocator on Windows needs to be fixed. What is the issue with it? I recall I pulled something recently. -- Andrei
Last - but not least! - two DConf talks
Spread the word! https://www.youtube.com/watch?v=bxSPCmwqgYs https://www.youtube.com/watch?v=jNQF3m5e2l0 Andrei
Re: clayers - Update 1.1.0
On Tuesday, 7 July 2015 at 19:09:05 UTC, Wyatt wrote:
Hey! I appreciate the feedback you've given!
Thoughts/ideas/suggestions:
* I think everyone working on this problem ends up making
coordinate types. ~_~;; I definitely recommend defining XCoord
and YCoord as separate types so a common inversion bug is
prevented-- that's saved me a number of times. In my
experience, a straight alias was vexingly insufficient so I use
a struct (though it's still not where I want it).
I don't really understand what you mean by this point, could you
elaborate?
The reason to why I have my own XY struct is mainly because I
often felt like I needed two varaibles, so simply making one felt
like an good idea.
* Make a no-args init that detects terminal dimensions. It's
just nicer that way.
Yes, I totally agree. Before I even released v1.0.0 this was how
the program functioned... until I tested it on OS X. For some
reason, there standard way on POSIX didn't work on OS X (see
https://github.com/vladdeSV/clayers/issues/2). And while I would
want an auto-size to be, it could be hard for developers to make
a game where the window size is relative. (Come to think of it,
it might actually not be.)
But yeah, the dimensions should be auto-set!
* I like the two-corner constructor for ConsoleLayer. I can't
remember why I didn't go that route myself. It may have been
that I was just trying to "make it work" instead of "make it
nice", but there could be something more. I forget.
If I understood you correctly, you are wrong :P. If you mean I
set location (5,0) and size(10,10), it doesn't create a layer
with those two as corners, rather the size adds to the location,
so the rightmost location is at (15, 0 .. 10). A two point corner
system would be very nice though, and it might happen in the
future.
* Relative (percentage-based) dimensions seem like they could
be really handy, but I've never figured out how to make them
feel good. Maybe you can do better.
I've never really tried with relative dimensions, just a hard set
that main window goes to 50, and sidebar starts at 50. If you
would like to expand on "feel good" that'd be very much
appreciated. (I know my self that the "feel" often can't be
explained, so no worries if you don't :) )
* Simplify bordered windows. I feel pretty strongly that that
should be abstracted into the ConsoleLayer, honestly. If not
as part of the constructor, then as a property you can set.
Default to nothing and allow setting it to a character ("#") or
to a manifest constant that tells it to use unicode box drawing
characters. (Or maybe the property is an enum BORDER {NONE,
UNICODE, CHAR}, and the character is separate? I don't know.)
Oh my, you don't know how much problems I've had with borders.
Buggy borders have been in the code pre-v1 (introduced here:
https://github.com/vladdeSV/clayers/commit/70a0547288aec8008d033c419ad3c387315c2125 and removed here: https://github.com/vladdeSV/clayers/commit/7249b9ed2a00a59a2867dd79861cf4bdee580f64). I've had many thoughts about borders, and to be honest, I didn't quite get how to make border work properly while at the same time make it user friendly. I had problems with writing to the layers as well, where text would overwrite borders and what not.
And if I made a layer 10x10 with a border, could I then write at
(0,0)? Would that be at the border, or the position inside the
border? And then the width/height? Would it return the whole
width, or the width where you could write. And then, what if
someone wants a border that is two characters wide, how would
that work? At the time I had no idea, and with the code I had
then, I felt it was more worth it to get a working engine rather
than fancy borders.
Generally speaking, they did less good than bad.
However, as you mention below, adding a second layer that is
inside the border would actually work, since my code (currently)
allows layers to have sub-layers (which can have more sub-layers,
which in turn can have... you get the idea. That's why sub-layers
still are a maybe).
* A method to get the current layer order is probably worth
considering. And a way to get the priority index for a layer.
And even relative reordering; e.g. layerA.moveAbove(layerB);
I have also considered getting the layer order, but ,how,
exactly? Would I get an ID of some sort? Would I need to set a
custom ID for each layer? What happens if two layers have the
same ID? Relative layers however seem like a nice thing to have,
and I'm pretty sure I could add that with little to no problems
:).
* There's no way to move or resize a layer? Is the the idea to
just destroy and recreate the layer with the new origin/size?
Resize and moving layers are things I've never though about. As
I've developed clayers, I've never once felt the need to move or
resize a layer. It is definitely possible to add these features,
however, things I do not know how to handle, such
Scriptlike v0.9.2
Minor update, Scriptlike v0.9.2: https://github.com/Abscissa/scriptlike - Fixed: Properly flush all command echoing output (ie, in yap and yapFunc). - Enhancement: Add a "no-build" configuration for projects that need to import/depend on Scriptlike through DUB, but use their own buildsystem.
Re: LDC for iOS prebuilt binaries
"Jack Stouffer" writes: > > Does this have any way to call the iOS Obj-C libraries for UI > rendering and the like? Or is that a separate project? It is a separate project and is gradually getting pulled into DMD: http://forum.dlang.org/post/mnm1sf$kp8$1...@digitalmars.com For now, you can write UI part in Objective-C and rest as D. From D you could call any of the C-based graphics APIs (e.g. CGContextFillRect) but you'd have to write declarations - or try out Dstep: https://github.com/jacob-carlborg/dstep Another approach is using a framework with D bindings like Allegro5. http://forum.dlang.org/post/m2sicg48ff@comcast.net This looked promising but I have not pursed beyond that post. -- Dan
LDC for iOS prebuilt binaries
On Thursday, 9 July 2015 at 06:32:28 UTC, Dan Olson wrote: Only 32-bit devices currently; arm64 work starts next month when I acquire an iPhone 6. The download should have everything needed to run on an OS X build host in the same fashion as LDC downloads. Great work. D will get a huge boost in popularity if it can work on mobile devices. Does this have any way to call the iOS Obj-C libraries for UI rendering and the like? Or is that a separate project?
Re: Voting for std.experimental.allocator
Yes!
