Re: Silicon Valley D Meetup - January 26, 2017 - "High Performance Tools in D" by Jon Degenhardt
On Saturday, 18 February 2017 at 21:22:33 UTC, Jon Degenhardt wrote: Regarding a blog post - I haven't talked to Mike Parker, if there's interest I'd be open to it. Yes, there is interest. I was planning to contact you about this in my next round of queries. So I suppose now we can skip the query and get right to the details.
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On 02/18/2017 08:42 PM, Nick Sabalausky (Abscissa) wrote:
Or it might be better to just toss this in around the top of the CSS:
--
input, textarea {
background-color: white;
color: #333;
}
--
K, just tested it, works for me:
https://github.com/dlang/dlang.org/pull/1576
Re: Silicon Valley D Meetup - January 26, 2017 - "High Performance Tools in D" by Jon Degenhardt
On Saturday, 18 February 2017 at 07:50:02 UTC, Joakim wrote: On Friday, 27 January 2017 at 18:20:53 UTC, Jon Degenhardt wrote: On Friday, 27 January 2017 at 16:21:51 UTC, Jack Stouffer wrote: On Friday, 27 January 2017 at 03:58:26 UTC, Ali Çehreli wrote: And this: http://youtu.be/-DK4r5xewTY Hey Jon, if you're in this thread, are you able to post any of the code that you use for tsv parsing? Code has been open-sourced: https://github.com/eBay/tsv-utils-dlang The performance benchmarks showed in the talk are not in the repo, the benchmarks currently listed are from a year ago. I'm planning to update the repo in the next few weeks, probably after the next LDC release. If there are questions about specific types of things perhaps a thread in General forum would work. --Jon Watched the video some time back, interesting results. Any plans to blog about this? It would be great if you could run them through a profiler too, see why D is so much faster. Would be really worth writing this up, maybe on the D blog. Thanks for the feedback. I'm pretty close to publishing the benchmarks, they'll go in a doc file in the repository. They weren't quite complete when the meetup happened. Regarding a blog post - I haven't talked to Mike Parker, if there's interest I'd be open to it. As to why the tools compare so well - That's a really intriguing question, especially since the tools favor using high level constructs from D / Phobos rather than hand-built data structures or memory management. I have hypotheses, but no sure answers. Some of it likely involves design choices rather than language facilities per se, but even so, it's a good story for D. --Jon
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Saturday, 18 February 2017 at 16:43:43 UTC, Seb wrote: Excellent idea! AFAIK reddit doesn't like self posts that much. Would someone be so kind to post this once the improvements are in? https://github.com/dlang/dlang.org/pull/1575 (this PR disables the `assert` transformation for now and also changes the output to pre. It will automatically be deployed once merged) I'll do it. But before I do, I'll want to know that everything is working as intended. Post here with a green light and I'll post it during one of the peak periods.
Re: tanya library 0.2.0
On Saturday, 18 February 2017 at 15:51:59 UTC, Eugene Wissner wrote: It isn't really a release announce, maybe a pre-release. tanya is a general purpose library, used mostly for networking by me. It is an attempt to develop an alternative memory model for D; 100% of the library are usable in @nogc code. Sounds really cool! tanya contains an event loop, containers, an URL parsing routine and alternative TCP sockets implementation, multiple precision integer. The library is cross plattform, but not thread-safe yet. Do you know about eventcore [1] (event loop abstraction)? I hope that this will soon be submitted to Phobos as everyone seems to be brewing their own solution and I am _not_ looking forward to manage to find a way to run five event loops when I want to use fix different libraries. [1] https://github.com/vibe-d/eventcore The memory management is based on allocators. The allocators are one-way compatible with std.experimental.allocator, it means my allocators can be used with std.exeperimental.allocator but the std.experimental.allocator isn't usable with my lbirary (though it is pretty straightforward to write a wrapper for phobos allocators). tanya's allocators follow Bloomberg Allocator Model, see discussions on BDE Allocator Model for pro and contra. From [2] and your API I get that the BDE API is: virtual void* allocate(size_type size) virtual void deallocate(void *address) whereas you extended this by: int alignment() void[] allocate(in size_t size) bool deallocate(void[] p) bool reallocate(ref void[] p, in size_t size) bool reallocateInPlace(ref void[] p, in size_t size) Well obviously the std.experimental.allocator protocol is more complicated: uint alignment() void[] allocate(size_t, TypeInfo ti = null) void[] alignedAllocate(size_t n, uint a) void[] allocateAll() bool expand(ref void[], size_t); bool reallocate(ref void[], size_t); bool alignedReallocate(ref void[] b, size_t size, uint alignment); Ternary owns(void[] b); Ternary resolveInternalPointer(void* p, ref void[] result); bool deallocate(void[] b); bool deallocateAll(); Ternary empty(); However I would be very interested in hearing your reasons for not using it. Keep in mind that std.experimental.allocator is supposed to be a general purpose library exactly to avoid everyone writing their own, incompatible Allocators ;-) So please raise your voice as long as it's still in experimental! [2] https://github.com/bloomberg/bde/wiki/BDE-Allocator-model
mysql-native v1.0.0-rc4
One more update to the MySQL/MariaDB client lib, hopefully the last
before v1.0.0 final.
This one actually includes quite a few more changes I wanted to get in
as long as it's making the big leap up to v1.0.0 (see below).
For now, this still lives in a separate fork:
https://github.com/Abscissa/mysql-native-experimental
To use it:
$ git clone https://github.com/Abscissa/mysql-native-experimental.git
$ dub add-local path/to/mysql-native-experimental
And then, when you're doing using this preview:
$ dub remove-local path/to/mysql-native-experimental
Docs here:
http://semitwist.com/mysql-native-docs/v1.0.0-rc4/
I'm going to give this a week. If no fundamental, release-delaying
issues/objections come up, and nobody speaks up that they could use more
time to evaluate it, then on Feb 26 I'll merge this branch back over to
the official mysql-native repo, and tag it as v1.0.0.
Changes in 'v1.0.0-rc4' since the previous preview, 'v0.2.0-preview3':
- Much more documentation improvement.
- Added a Prepared.sql getter, to retrieve the sql for a prepared
statement. (Previously it was inaccessible.)
- ResultSet.asAA and ResultRange.asAA now return Variant[string] instead
of DBValue[string]. DBValue is no longer needed and now deprecated (as
it was only used by `asAA` and Variant now handles null properly.)
- Fixed: Row.isNull(index) isn't a setter, so don't mark it @property
(confuses the doc generator).
- Rename MySqlPool to MySQLPool to be consistent with other parts of the
API.
- MySQLPool now supports vibe.d's ConnectionPool.maxConcurrency feature.
- Improved separation between internal ("mysql.protocol") and external
interfaces.
- No longer publicly imports internal-only symbols by default.
- Renamed module `mysql.protocol.commands` to `mysql.commands`.
- Renamed module `mysql.protocol.prepared` to `mysql.prepared`.
- Moved `ParameterSpecialization` into `mysql.prepared` (was in
`mysql.protocol.extra_types`).
- Moved `ColumnSpecialization` into `mysql.commands` (was in
`mysql.protocol.extra_types`).
- Moved the other public-API members of `mysql.protocol.extra_types`
into new modules `mysql.metadata` and `mysql.types`.
- Split module "mysql.common" into two different modules:
"mysql.exceptions" and "mysql.protocol.socket"
I also reorganized/rewrote the v1.0.0 changelog entry to be a bit more
readable, so take a look at the overall changes from the previous
release, v0.1.7, to this latest release candidate, v1.0.0-rc4
https://github.com/Abscissa/mysql-native-experimental/blob/master/CHANGELOG.md
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On 02/18/2017 11:48 AM, Seb wrote:
On Friday, 17 February 2017 at 16:07:37 UTC, Nick Sabalausky (Abscissa)
wrote:
1. This is pretty awesome.
Thanks a lot :)
2. Looks like someone forgot to set a foreground text color for the
output even though the background is set to white. This makes the
output text invisible for those using eye-friendly light-on-dark systems.
I am not sure I follow. Do you use a custom color scheme or plugin that
sets the body background color to black?
Dark system color scheme, nothing mucking with website CSSes or
anything. Somewhat bizarrely/irritatingly, there are certain cases
( and to my knowledge, maybe others) where browsers
inherit default color settings from the OS[1] instead of from a built-in
browser-default CSS.
Since my OS is set up to default to (near-)white text on a (near-)black
background, the browser decides "Oh, ok, I'll use white text on a black
background for inputs and textareas." But then the site's CSS tells it
to use a white background. And says nothing about text color. Browser
says: "Ok! So, white text (system textbox default) on a white background
(website CSS)!!"
[1] Browsers taking theme defaults from the OS was appropriate behavior
back in HTML1 when the whole web was actually designed from the
ground-up to automatically adapt to the machine being used. But not so
much now that every site/page in the world uses its own theme and
formatting system[2], and even the browser's own default css *mostly*
(with, of course, these broken exceptions) separates itself from the OS,
leaving occasionally broken readability.
[2] The site-chosen formatting system occasionally being one that
attempts to partially adapt to the local machine, to varying degrees of
success. Thanks, legacy of HTML2/4!
Did I mention I hate web browsers? ;)
What exactly would be the best way for you to resolve your problem?
Maybe you can even submit a PR yourself? - the CSS is here:
https://github.com/dlang/dlang.org/blob/master/css/style.css#L1611
I'm working out building the site locally right now so I can test
(building it seems to be taking awhile), but:
Looks like the site is mostly using #333 for text color. You could just
toss in "color: #333;" right next to "background: white;" for the
d_code_output sections (might not matter for the div version, but
wouldn't hurt either.) That should work.
Or it might be better to just toss this in around the top of the CSS:
--
input, textarea {
background-color: white;
color: #333;
}
--
Re: Vibrant 2.0, major update
On Friday, 17 February 2017 at 20:45:53 UTC, Relja Ljubobratovic wrote: On Monday, 13 February 2017 at 14:22:25 UTC, Guillaume Piolat wrote: It's the 10th update for this abstract shooter made in D. This is the first time I've heard of this game. Downloaded the demo, and first impressions were mind blowing! Gameplay seems very fluid and well calibrated. But, I've got to say - most awesome element of the gameplay is definitely the music! This might be the most impressive sound I've heard coming from my macbook since I've bought it! Truly drives the mood in the game. :) I've gladly payed for the full version, and will spread the word of this game whenever I can. Congrats, and thank you! (On Friday, 17 February 2017 at 20:45:53 UTC, Relja Ljubobratovic wrote: On Monday, 13 February 2017 at 14:22:25 UTC, Guillaume Piolat wrote: It's the 10th update for this abstract shooter made in D. This is the first time I've heard of this game. Downloaded the demo, and first impressions were mind blowing! Gameplay seems very fluid and well calibrated. But, I've got to say - most awesome element of the gameplay is definitely the music! This might be the most impressive sound I've heard coming from my macbook since I've bought it! Truly drives the mood in the game. :) I've gladly payed for the full version, and will spread the word of this game whenever I can. Congrats, and thank you! It's a blessing to have some happy players :) Music is obviously an integral part of the game, and apparently when Nelson did it (perhaps 10 years ago?) it was a live performance. I'll forward him your kind message. (regular readers: sorry for the noise and promotion)
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
Am 17.02.2017 um 22:07 schrieb Dmitry Olshansky: On 2/17/17 6:06 AM, Seb wrote: On Saturday, 7 January 2017 at 16:12:49 UTC, Andrei Alexandrescu wrote: Following https://github.com/dlang/dlang.org/pull/1532, the new-style docs now also allow editing and running examples. Start at http://dlang.org/library-prerelease/ and go anywhere to check it out. Broken on the first example I tried :( http://dlang.org/library-prerelease/std/algorithm/searching/find.html --- Dmitry Olshansky The example got cut off two or three characters too early, compared with the source unit test. I'll have to check if this is an issue with DDOX, or with the JSON output.
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
Am 18.02.2017 um 14:43 schrieb Sönke Ludwig: Am 17.02.2017 um 22:07 schrieb Dmitry Olshansky: On 2/17/17 6:06 AM, Seb wrote: On Saturday, 7 January 2017 at 16:12:49 UTC, Andrei Alexandrescu wrote: Following https://github.com/dlang/dlang.org/pull/1532, the new-style docs now also allow editing and running examples. Start at http://dlang.org/library-prerelease/ and go anywhere to check it out. Broken on the first example I tried :( http://dlang.org/library-prerelease/std/algorithm/searching/find.html --- Dmitry Olshansky The example got cut off two or three characters too early, compared with the source unit test. I'll have to check if this is an issue with DDOX, or with the JSON output. Hm, okay, false alert. The characters are there in the page sources and get cut off by the JS that transforms the HTML.
tanya library 0.2.0
It isn't really a release announce, maybe a pre-release. tanya is a general purpose library, used mostly for networking by me. It is an attempt to develop an alternative memory model for D; 100% of the library are usable in @nogc code. I previously announced that I want to merge my code with another project and that I would stop the development. But it didn't happen. I'm sorry that I wanted to abandon it. It won't happen anymore. I'll continue the development. tanya contains an event loop, containers, an URL parsing routine and alternative TCP sockets implementation, multiple precision integer. The library is cross plattform, but not thread-safe yet. The memory management is based on allocators. The allocators are one-way compatible with std.experimental.allocator, it means my allocators can be used with std.exeperimental.allocator but the std.experimental.allocator isn't usable with my lbirary (though it is pretty straightforward to write a wrapper for phobos allocators). tanya's allocators follow Bloomberg Allocator Model, see discussions on BDE Allocator Model for pro and contra. And sorry once again for a long post... What's new: - Bug fixes and performance improvements in the main allocator: MmapPool. - Container redesign: There is a new container, Vector (similar to std.container.array) with the support of ranges and all the cool stuff. I also started to experiment with the "move" semantics in D based on the D conf talk of Ali Çehreli. There are also a singly linked list, circular buffer and a queue. SList will get range support soon, and some time later the buffers. - Bug fixes in the epoll event loop and a few new features. - RefCounted: more similar to C++ shared_ptr than to phobos' RefCounted, but more primitive. Future plans: I still need a few more containers: UTF-8 string and a hash table. The string won't be the same as RCString. I'm thinking of a not templated string with UTF-8 support only (with a possibility to initialize it from a string, dstring and wstring). Big integer bug fixing and optimization has a priority aswell for me. I'm also planning to add streams but it won't happen very soon since it is a lot of work. I plan to start a small blog in April based on the library (university project). It will be a SCGI-server, serving only static pages, behind Apache. It will be the first try-out :). From there I can move to a http-server. The library is still under permanent development. I begin to care about the API stability and proper deprecations, but it isn't always possible. I intend to make releases regularly, maybe all the 6 weeks and to prepare some new features for each of the releases. The API docs for the latest version can be found on https://docs.caraus.io/tanya/ If you have questions, need some examples, let me know. I'll write something up and publish it somewhere. https://github.com/caraus-ecms/tanya http://code.dlang.org/packages/tanya https://docs.caraus.io/tanya/
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Saturday, 18 February 2017 at 13:46:10 UTC, Sönke Ludwig wrote: Am 18.02.2017 um 14:43 schrieb Sönke Ludwig: Am 17.02.2017 um 22:07 schrieb Dmitry Olshansky: On 2/17/17 6:06 AM, Seb wrote: On Saturday, 7 January 2017 at 16:12:49 UTC, Andrei Alexandrescu wrote: Following https://github.com/dlang/dlang.org/pull/1532, the new-style docs now also allow editing and running examples. Start at http://dlang.org/library-prerelease/ and go anywhere to check it out. Broken on the first example I tried :( http://dlang.org/library-prerelease/std/algorithm/searching/find.html --- Dmitry Olshansky The example got cut off two or three characters too early, compared with the source unit test. I'll have to check if this is an issue with DDOX, or with the JSON output. Hm, okay, false alert. The characters are there in the page sources and get cut off by the JS that transforms the HTML. Yeah the regex trick doesn't seem to work that well: -> https://github.com/dlang/dlang.org/pull/1575 (disables the `assert` transformation for now and also changes the output to pre)
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Friday, 17 February 2017 at 08:00:29 UTC, Jack Stouffer wrote: On Friday, 17 February 2017 at 05:06:20 UTC, Seb wrote: Short follow-up: this is now live for the released documentation pages. Enjoy! Please make a post on Reddit! I firmly believe that this puts D at the top of programming language docs. We should advertise! Excellent idea! AFAIK reddit doesn't like self posts that much. Would someone be so kind to post this once the improvements are in? https://github.com/dlang/dlang.org/pull/1575 (this PR disables the `assert` transformation for now and also changes the output to pre. It will automatically be deployed once merged)
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Friday, 17 February 2017 at 16:07:37 UTC, Nick Sabalausky (Abscissa) wrote: 1. This is pretty awesome. Thanks a lot :) 2. Looks like someone forgot to set a foreground text color for the output even though the background is set to white. This makes the output text invisible for those using eye-friendly light-on-dark systems. I am not sure I follow. Do you use a custom color scheme or plugin that sets the body background color to black? What exactly would be the best way for you to resolve your problem? Maybe you can even submit a PR yourself? - the CSS is here: https://github.com/dlang/dlang.org/blob/master/css/style.css#L1611
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Friday, 17 February 2017 at 13:50:48 UTC, John Colvin wrote: Might I suggest you change the output s to s with border: none; and max-height: 30em; This would make them auto-grow to the right height to fit the content (with max-height for sanity). It does mean you lose manual resizability (unless you mess around in js to sort out the clash with max-height)), but that doesn't seem so important if it auto-resizes. Excellent idea! As the same js is used for the runnable boxes on the dlang.org main page, I didn't want to touch the editor that much (initially). Anyway I submitted a PR that changes the output element to : https://github.com/dlang/dlang.org/pull/1575 As imho the border doesn't look that bad and for the same reason as above I didn't remove the border. See a visual comparison here: http://imgur.com/a/pElAu Are you or others still in favor of removing the border?
