Re: photon v0.9.0 with Go-style D-flavored channels!
On Friday, 3 May 2024 at 17:12:40 UTC, Dmitry Olshansky wrote:
On Monday, 29 April 2024 at 20:50:59 UTC, Dmitry Olshansky
wrote:
On Monday, 29 April 2024 at 20:50:24 UTC, Dmitry Olshansky
wrote:
Photon is a minimalistic multi-threaded fiber scheduler and
event loop that works transparently with traditional blocking
I/O C/C++/D/Rust libraries w/o degrading performance.
And now we have Channels, gentelmen. The only missing bit is
`select` function to multiplex on a bunch of channels.
And the wait is over! Now there is a select function to multiplex
on read side of a bunch of channels. This also fixes a bug in the
poll syscall override with multiple events on posix systems
https://github.com/DmitryOlshansky/photon/blob/master/examples/select.d
```d
module examples.select;
import std.range, std.datetime, std.stdio;
import photon;
void main() {
startloop();
auto first = channel!(int)(2);
auto second = channel!(string)(1);
go({
delay(500.msecs);
first.put(0);
first.put(1);
delay(500.msecs);
second.put("ping");
});
go({
foreach ( _; 0..3) {
select(
first, {
writefln("Got first %s", first.take(1));
},
second, {
writefln("Got second %s", second.take(1));
}
);
}
});
runFibers();
}
```
---
Dmitry Olshansky
CEO @ [Glow labs](https://glow-labs.pro)
https://olshansky.me/about/
photon v0.9.0 with Go-style D-flavored channels!
On Monday, 29 April 2024 at 20:50:59 UTC, Dmitry Olshansky wrote:
On Monday, 29 April 2024 at 20:50:24 UTC, Dmitry Olshansky
wrote:
Photon is a minimalistic multi-threaded fiber scheduler and
event loop that works transparently with traditional blocking
I/O C/C++/D/Rust libraries w/o degrading performance.
And now we have Channels, gentelmen. The only missing bit is
`select` function to multiplex on a bunch of channels.
So here is example of Go-style, D-flavored channels:
```d
import std.algorithm, std.datetime, std.range, std.stdio;
import photon;
void first(shared Channel!string work, shared Channel!int
completion) {
delay(2.msecs);
work.put("first #1");
delay(2.msecs);
work.put("first #2");
delay(2.msecs);
work.put("first #3");
completion.put(1);
}
void second(shared Channel!string work, shared Channel!int
completion) {
delay(3.msecs);
work.put("second #1");
delay(3.msecs);
work.put("second #2");
completion.put(2);
}
void main() {
startloop();
auto jobQueue = channel!string(2);
auto finishQueue = channel!int(1);
go({
first(jobQueue, finishQueue);
});
go({ // producer # 2
second(jobQueue, finishQueue);
});
go({ // consumer
foreach (item; jobQueue) {
delay(1.seconds);
writeln(item);
}
});
go({ // closer
auto completions = finishQueue.take(2).array;
assert(completions.length == 2);
jobQueue.close(); // all producers are done
});
runFibers();
}
```
Obligatory link:
https://github.com/DmitryOlshansky/photon
---
Dmitry Olshansky
CEO @ [Glow labs](https://glow-labs.pro)
https://olshansky.me/about/
Re: photon v0.8.0 with Events, Semaphores and Timers
On Monday, 29 April 2024 at 20:50:24 UTC, Dmitry Olshansky wrote: Photon is a minimalistic multi-threaded fiber scheduler and event loop that works transparently with traditional blocking I/O C/C++/D/Rust libraries w/o degrading performance. This release brings in new APIs for Events, Semaphores and Timers, on all 3 supported platforms (Windows, Linux and MacOS)! For now, only fibers can use the primitives but in the next version sharing of Event or Semaphore between fibers and plain threads is planned. Obligatory link: https://github.com/DmitryOlshansky/photon -- Dmitry Olshansky CEO @ [Glow Labs](https://glow-labs.pro) https://olshansky.me/about/
photon v0.8.0 with Events, Semaphores and Timers
Photon is a minimalistic multi-threaded fiber scheduler and event loop that works transparently with traditional blocking I/O C/C++/D/Rust libraries w/o degrading performance. This release brings in new APIs for Events, Semaphores and Timers, on all 3 supported platforms (Windows, Linux and MacOS)! For now, only fibers can use the primitives but in the next version sharing of Event or Semaphore between fibers and plain threads is planned. -- Dmitry Olshansky CEO @ [Glow Labs](https://glow-labs.pro) https://olshansky.me/about/
Re: photon v0.7.0 with Windows support(!)
On Wednesday, 24 April 2024 at 14:40:40 UTC, Steven Schveighoffer wrote: On Tuesday, 23 April 2024 at 19:05:48 UTC, Dmitry Olshansky wrote: On Tuesday, 23 April 2024 at 17:15:13 UTC, Sönke Ludwig wrote: I guess that the Darwin support will be restricted to freely distributed macOS applications, as calling `__syscall` surely is a private API that cannot be used in any AppStore application, right? You tell me;) API looks just like any other libc function. I can tell you right off that this will not be allowed in approved apps. Not just for the `__syscall`, but for overriding the normal system calls of all libraries. I can't imagine Apple will be OK with that. How would they know? The whole thing happens at the link time. — Dmitry Olshansky CEO @ Glowlabs https://olshansky.me
Re: photon v0.7.0 with Windows support(!)
On Tuesday, 23 April 2024 at 17:15:13 UTC, Sönke Ludwig wrote: Am 21.04.2024 um 21:01 schrieb Dmitry Olshansky: Photon is a minimalistic multi-threaded fiber scheduler and event loop that works transparently with traditional blocking I/O C/C++/D/Rust libraries w/o degrading performance. It took somewhat longer than I wanted but I'm pleased to announce that Photon now supports Windows. In particular basic socket API that is used by the likes of std.socket is transparently converted to overlapped I/O with I/O completion port event loop. The last obstacle was, of course, accept syscall that is only blocking on Windows. Now that transparently goes to a dedicated Windows's native threadpool so as to not block our precious fibers. Explore some basic examples here (not all examples can be run on Windows): https://github.com/DmitryOlshansky/photon/tree/master/tests -- Dmitry Olshansky CEO @ Glowlabs https://olshansky.me That's really nice! How would you judge supporting other kinds of handles, such as files or events, on Windows? Going to be tricky but timers for one thing should work with the threadpool I got in there. I guess that the Darwin support will be restricted to freely distributed macOS applications, as calling `__syscall` surely is a private API that cannot be used in any AppStore application, right? You tell me;) API looks just like any other libc function. In that case it would inevitably put it in a non-consumer application niche, but certainly wouldn't make it any less interesting for more server oriented tasks. My main angle is being able to develop servers / clients on MacOS deploying to other platforms such as Linux server. — Dmitry Olshansky CEO @ Glowlabs https://olshansky.me
Re: photon v0.7.0 with Windows support(!)
On Sunday, 21 April 2024 at 19:32:20 UTC, Dmitry Olshansky wrote: On Sunday, 21 April 2024 at 19:01:04 UTC, Dmitry Olshansky wrote: [...] It gets better, now with hotfixed HTTP hello world example: https://github.com/DmitryOlshansky/photon/blob/master/bench/static_http/hello.d Messed things up with hotfix leaving debug tracing enabled even in production builds, please use v0.7.2. -- Dmitry Olshansky CEO @ GLowlabs https://olshansky.me
Re: photon v0.7.0 with Windows support(!)
On Sunday, 21 April 2024 at 19:01:04 UTC, Dmitry Olshansky wrote: Photon is a minimalistic multi-threaded fiber scheduler and event loop that works transparently with traditional blocking I/O C/C++/D/Rust libraries w/o degrading performance. It took somewhat longer than I wanted but I'm pleased to announce that Photon now supports Windows. In particular basic socket API that is used by the likes of std.socket is transparently converted to overlapped I/O with I/O completion port event loop. The last obstacle was, of course, accept syscall that is only blocking on Windows. Now that transparently goes to a dedicated Windows's native threadpool so as to not block our precious fibers. Explore some basic examples here (not all examples can be run on Windows): https://github.com/DmitryOlshansky/photon/tree/master/tests -- Dmitry Olshansky CEO @ Glowlabs https://olshansky.me It gets better, now with hotfixed HTTP hello world example: https://github.com/DmitryOlshansky/photon/blob/master/bench/static_http/hello.d -- Dmitry Olshansky CEO @ GLowlabs https://olshansky.me
Re: photon v0.6.0 with MacOS support
On Friday, 12 April 2024 at 17:04:33 UTC, Richard (Rikki) Andrew Cattermole wrote: On 13/04/2024 4:57 AM, Dmitry Olshansky wrote: Next on schedule is Windows support. I see that you left the hard one for last. Good luck! Happy book buying. I had an intriguing implementation for it running on top of User Mode Scheduling, sadly Windows folks deprecated User Mode Scheduling thus leaving me with a bunch of work and likely a narrower scope.
photon v0.6.0 with MacOS support
Photon is a transparent fibre scheduler library making traditional sync I/O async without modification of underlying boring blocking code. https://github.com/DmitryOlshansky/photon For usage see simple examples in the tests directory. This release brings MacOS support, thanks to Steve Schveighoffer. Next on schedule is Windows support. -- Dmitry Olshansky CEO @ Glowlabs https://olshansky.me
Pry parser v0.6.0 is out
Not much in way of new features but now atom set actually take a set as runtime parameter making it all the more useful. https://github.com/DmitryOlshansky/pry-parser -- Dmitry Olshansky CEO @ Glow Labs http://olshansky.me
Re: shareded-map v1.0.0
On Monday, 26 June 2023 at 08:50:01 UTC, Dmitry Olshansky wrote: On Monday, 26 June 2023 at 08:48:38 UTC, Dmitry Olshansky wrote: Shredded map v1.0.0 is out! Simple scalable concurrent hash map based on built-in D hash maps. It's simply shared by key. License is Boost v1. -- Dmitry Olshansky https://sponsr.ru/glow The link: https://github.com/DmitryOlshansky/sharded-map v2.0.0 with multi map is now on. -- Dmitry Olshansky https://olshansky.me
Re: Get ready your Playstation 5 controllers
On Tuesday, 27 June 2023 at 12:07:14 UTC, Ferhat Kurtulmuş wrote: Here is a gui program testing your PS5 controllers on Windows. DWT is used for gui. Only missing part is lack of setting triggers' resistances at the moment. There is a problem with battery level too. https://github.com/aferust/testds5 Impressive! — Dmitry Olshansky https://olshansky.me
Re: shareded-map v1.0.0
On Tuesday, 27 June 2023 at 07:57:31 UTC, a11e99z wrote: On Monday, 26 June 2023 at 08:50:01 UTC, Dmitry Olshansky wrote: On Monday, 26 June 2023 at 08:48:38 UTC, Dmitry Olshansky wrote: Shredded map v1.0.0 is out! Simple scalable concurrent hash map based on built-in D hash maps. It's simply shared by key. Dmitry Olshansky The link: https://github.com/DmitryOlshansky/sharded-map .opApply w/o locks? Locking one shard at a time.
Re: shareded-map v1.0.0
On Monday, 26 June 2023 at 10:31:48 UTC, Dmitry Olshansky wrote: On Monday, 26 June 2023 at 09:45:25 UTC, Sergey wrote: On Monday, 26 June 2023 at 08:50:01 UTC, Dmitry Olshansky wrote: On Monday, 26 June 2023 at 08:48:38 UTC, Dmitry Olshansky wrote: [...] The link: https://github.com/DmitryOlshansky/sharded-map Concurrent data structures are hard. Any plans to increase number of methods so that the solution will be comparable with more mature options like https://docs.rs/dashmap/5.3.4/dashmap/struct.DashMap.html https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html That's the plan, but the added goals is to keep its implementation simple. -- Dmitry Olshansky Now with length and foreach! -- Dmitry Olshansky
Re: shareded-map v1.0.0
On Monday, 26 June 2023 at 09:45:25 UTC, Sergey wrote: On Monday, 26 June 2023 at 08:50:01 UTC, Dmitry Olshansky wrote: On Monday, 26 June 2023 at 08:48:38 UTC, Dmitry Olshansky wrote: Shredded map v1.0.0 is out! Simple scalable concurrent hash map based on built-in D hash maps. It's simply shared by key. License is Boost v1. -- Dmitry Olshansky https://sponsr.ru/glow The link: https://github.com/DmitryOlshansky/sharded-map Concurrent data structures are hard. Any plans to increase number of methods so that the solution will be comparable with more mature options like https://docs.rs/dashmap/5.3.4/dashmap/struct.DashMap.html https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html That's the plan, but the added goals is to keep its implementation simple. -- Dmitry Olshansky
Re: shareded-map v1.0.0
On Monday, 26 June 2023 at 08:48:38 UTC, Dmitry Olshansky wrote: Shredded map v1.0.0 is out! Simple scalable concurrent hash map based on built-in D hash maps. It's simply shared by key. License is Boost v1. -- Dmitry Olshansky https://sponsr.ru/glow The link: https://github.com/DmitryOlshansky/sharded-map
shareded-map v1.0.0
Shredded map v1.0.0 is out! Simple scalable concurrent hash map based on built-in D hash maps. It's simply shared by key. License is Boost v1. -- Dmitry Olshansky https://sponsr.ru/glow
Re: D Language Foundation Monthly Meeting Summary for May 2023
On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote: The monthly meeting for May 2023 took place on Friday the 5th at 14:00 UTC. It lasted about an hour and a half. This was the last meeting before we started our new planning sessions. Nice to read on what you guys are doing! — Dmitry Olshansky CEO at Glow labs https://sponsr.ru/glow https://patreon.com/dmitry_glow_labs
Re: Centroid tracking using DCV
On Friday, 23 June 2023 at 07:26:03 UTC, Ferhat Kurtulmuş wrote: On Friday, 23 June 2023 at 05:07:26 UTC, Dmitry Olshansky wrote: On Wednesday, 15 February 2023 at 17:32:33 UTC, Ferhat Kurtulmuş wrote: [...] Cool stuff! I once contributed Randomized Hough transform to DCV. [...] Hello Dmitry, Can you please take a look at the RHT test code? And please review my modifications on your code due to API changes over time. The circles are not detected in the RHT example at the moment. Maybe I broke something while doing things nog. I’m on vacation but I’ll take a look. https://github.com/libmir/dcv/blob/master/examples/rht/source/app.d https://github.com/libmir/dcv/blob/master/source/dcv/features/rht.d
Re: Centroid tracking using DCV
On Wednesday, 15 February 2023 at 17:32:33 UTC, Ferhat Kurtulmuş wrote: I heard you are not having fun enough with d today. Do you know you can do things like this with dlang now? After some fiddling with it, my last commits made this possible. Cool stuff! I once contributed Randomized Hough transform to DCV. how it looks like: https://www.youtube.com/watch?v=ACC_-TDAtqc source code: https://github.com/aferust/oclcv/tree/main/examples/centroidtracking DCV: https://github.com/libmir/dcv Sorry for the potato-quality video. My art director is on vacation. I am cheating a little with OpenCL since things are not fast enough at the moment. Hope you like it. Enjoy!
Glow labs on Patreon
To keep it simple my all D opensource company now has patreon page: https://www.patreon.com/dmitry_glow_labs
Re: You can now sponsor Photon and related projects
On Thursday, 20 April 2023 at 01:14:58 UTC, Dmitry Olshansky wrote: I think it only works in Russia, but here it is: https://sponsr.ru/feed/ Wrong link, sorry about that. https://sponsr.ru/glow — Dmitry Olshansky
You can now sponsor Photon and related projects
I think it only works in Russia, but here it is: https://sponsr.ru/feed/ — Dmitry Olshansky
Photon v0.3.0 is out!
Photon is transparent fiber i/o scheduler and a platform fo upcoming Hymera polyglot app server (https://github.com/glow-stack/hymera). What's new? - spawnLight and spawnHeavy to cleanly denote spawning light user mode thread vs OS thread, spawn is a synonym for spawLight - dopped HTTP parser library for Photon project source code, will be packaged separately P.S. Glow labs will continue to deliver on the promise of Boost licencing our core of business. -- Dmitry Olshansky CEO "Glow Labs"
Photon v0.1.1 is out!
I've been revising the cira 2018 code of Photon and realized it's quite well designed for a public beta. Examples The use of std.net.curl augmented by Photon to scale well: https://github.com/DmitryOlshansky/photon/blob/master/tests/curl_download.d Other syntetic tests may serve as examples: https://github.com/DmitryOlshansky/photon/tree/master/tests Github: https://github.com/DmitryOlshansky/photon DUB: https://code.dlang.org/packages/photon -- Dmitry Olshansky
Re: Beta 2.103.0
On Thursday, 2 March 2023 at 15:56:35 UTC, ryuukk_ wrote:
On Thursday, 2 March 2023 at 14:40:04 UTC, Iain Buclaw wrote:
Glad to announce the first beta for the 2.103.0 release, ♥ to
the 43 contributors.
This release comes with 9 major changes, including:
- In the compiler, `-preview=dip25` is now enabled by default.
- In the standard library, std.uni Grapheme functions have
been updated to conform to Unicode 15
- In dub, the `--color` argument now accepts the values
`auto`, `never`, and `always`.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.103.0.html
As usual please report any bugs at https://issues.dlang.org
-Iain
on behalf of the Dlang Core Team
```D
@safe ref int wrongIdentity(ref int x) {
return x; // ERROR! Cannot return a ref, please use "return
ref"
}
@safe ref int identity(return ref int x) {
return x; // fine
}
```
a keyword to return a value
``return 5;``
and a keyword to tell that a reference is returnable
``return ref int x``
that's dumb, why?
return ref is probably the tipping point for me. Even if better
keyword is used the accrual of complexity never ends. Though
arguably transitive qualifiers and inout were the point of no
return. Recently I had a case where in 64-bit mode a
data-structure could be implicitly converted to immutable while
in 32-bit it wouldn’t. After some mucking around a seemingly
unrelated change fixed it, the error message gave no clue of
what’s wrong.
Anyway I’d have a hard time selling transitive qualifiers in
particular shared, as most of the time shared object is taken off
the queue and should become thread-local. The type system doesn’t
want to hear any of it. Seems like ownership system beats
transitive qualifiers here, albeit both add significant friction.
—
Dmitry Olshansky
Re: Pijamas, a simple fluent assertation library (forked from Pyjamas)
On Friday, 15 May 2020 at 12:35:27 UTC, Luis wrote: On my run to raise stuff from dead packages, I come with Pijamas. A fork from Yamadacpc’s Pyjamas that works with D frontend 2.090 and forwards. [...] I was about to ask what is broken with ctRegex (well except that compiler usually explodes trying to swallow it) [...]
Re: On the D Blog: Lomuto's Comeback
On Thursday, 14 May 2020 at 13:26:23 UTC, Mike Parker wrote: After reading a paper that grabbed his curiosity and wouldn't let go, Andrei set out to determine if Lomuto partitioning should still be considered inferior to Hoare for quicksort on modern hardware. This blog post details his results. Fantastic work and great result. Having privately done a very heavy critique of the narrow niche the article had chosen to explore I still recognize and love the results. — Dmitry Olshansky
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Wednesday, 13 May 2020 at 12:26:48 UTC, user1234 wrote: On Tuesday, 12 May 2020 at 07:52:29 UTC, Dmitry Olshansky wrote: I find that I can vaguely amusing 100% of the day and I love standup comedy... "standup" lol. That reminds mesomeone who likes this genre too but he's not here anymore... you see just in case of... Well if I will not run out of steam in a year or so he’ll find me anyhow.
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Wednesday, 13 May 2020 at 07:02:20 UTC, Dmitry Olshansky wrote: On Tuesday, 12 May 2020 at 07:52:29 UTC, Dmitry Olshansky wrote: I find that I can vaguely amusing 100% of the day and I love standup comedy... And I’m too lame to figure out how do you open a brand channel on youtube. Anyone did that before? Was it that hard? Hope there is blood ritual involved, I expect anything now that I wasted 20 minutes and I’m only getting close to open it.
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Tuesday, 12 May 2020 at 07:52:29 UTC, Dmitry Olshansky wrote: I find that I can vaguely amusing 100% of the day and I love standup comedy... So I thought maybe I can give it a shot with a youtube channel? I already invent a cool personality - think Dirk Gently in computer science setting;) BTW for those of us who can’t do google search with a single click because of poor browser integration with the ecosystem, it’s this stuff: https://en.wikipedia.org/wiki/Dirk_Gently_(TV_series) It’s hilarious. Monthy Python is classic and all, but this stuff - totally insane and incredibly long chains of jokes, just what I like in humor the most... If that seems cool to you shoot me an email, or reply in this thread ... I need to the count to have a rough estimate of how low the size of my initial audience is..
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Wednesday, 13 May 2020 at 06:52:55 UTC, Basile B. wrote: On Tuesday, 12 May 2020 at 07:52:29 UTC, Dmitry Olshansky wrote: I find that I can vaguely amusing 100% of the day and I love standup comedy... So I thought maybe I can give it a shot with a youtube channel? I already invent a cool personality - think Dirk Gently in computer science setting;) If that seems cool to you shoot me an email, or reply in this thread ... I need to the count to have a rough estimate of how low the size of my initial audience is.. I rarely watch videos about programming (even talk) but I'd certainly take a look if you start something. It cant be worst than one of these tutorial produced by random Indian guys. Let’s put this way - if you don’t like it 10 minutes in - I owe you 1 VBJ token, it’s kind 1 favor ask anything digital currency. Simple GNU PG with funny trxt signed by my key + I’ll post the fingerprint EVERYWHERE just in case...
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Tuesday, 12 May 2020 at 19:52:35 UTC, Dmitry Olshansky wrote: Depending on what it looks like when it is finished. If it should have a teaching aspect, you would need to collect the sources and information into the video description. I’m going to describe the way I do creative work and try to capture this fleeting moment of me discovering something new. I have started my own company as of 1 day ago. I have no idea where I will be in one year with that but sure as hell I’m having fun and I have an array of ambitious projects already in the works. I want to explore what a Holistic Computer Scientist at work looks like. Just in case - if you have lot of cash on your hands and no idea on where to invest (these days it takes a blood while to figure it out)... Glow labs is a new R&D company run by a guy you probably know due to past DConf and stuff. I’m doing my own ICO with my own coin, and it’s more like strong collectible even in case I’m broke(!) digital obligation thing. I believe that is the future of digital currency, in fact I’m living in that future but it gets kind lonely here... Contact me if that’s something you can relate to ... Maybe — Dmitry Olshansky
Re: Release D 2.092.0
On Tuesday, 12 May 2020 at 19:50:10 UTC, Martin Nowak wrote: Glad to announce D 2.092.0, ♥ to the 47 contributors. This release comes with support for a prototype ownership/borrowing system for pointers, GNU ABI tags for extern(C++), printf format checks, and SOURCE_DATE_EPOCH for reproducible builds. http://dlang.org/download.html http://dlang.org/changelog/2.092.0.html And the releases still roll! It was way more hectic back in the day. Thanks for the good work, Martin, hope to see you some time next year.
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Tuesday, 12 May 2020 at 16:23:42 UTC, Jan Hönig wrote: On Tuesday, 12 May 2020 at 08:35:20 UTC, Dmitry Olshansky wrote: On Tuesday, 12 May 2020 at 07:52:29 UTC, Dmitry Olshansky wrote: If that seems cool to you shoot me an email, or reply in this thread ... I need to the count to have a rough estimate of how low the size of my initial audience is.. Okay, it quickly gets out of hand and I need to get back to work I think. I would check it out. I also think quite a lot of people could watch it. Depending on what it looks like when it is finished. If it should have a teaching aspect, you would need to collect the sources and information into the video description. I’m going to describe the way I do creative work and try to capture this fleeting moment of me discovering something new. I have started my own company as of 1 day ago. I have no idea where I will be in one year with that but sure as hell I’m having fun and I have an array of ambitious projects already in the works. I want to explore what a Holistic Computer Scientist at work looks like. The whole idea of doing funny, maybe even silly things that all eventually prove to be completely nessasary. Which is the key part of Dirk Gently experience - whatever you decide to do - it will have meaning even if it will only be clear long after the fact.
Re: OT: Back
On Tuesday, 12 May 2020 at 08:11:03 UTC, Bastiaan Veelo wrote: On Tuesday, 12 May 2020 at 07:48:46 UTC, Dmitry Olshansky wrote: Bastian! Great to see you still around. How your D stuff is going at that naval company? First real application is running: a program for the numerical analysis of a ship launch at the yard. Currently testing and debugging. Pain points typically revolve around low level tricks in Pascal using arrays starting at 1 (these usually translate without problems, except where they don't)... Or passing strings to/from win32. Still committed to translate all other programs in our suite to D, busy times as usual. Cool stuff. Keep it rolling ;) -- Bastiaan.
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Tuesday, 12 May 2020 at 07:52:29 UTC, Dmitry Olshansky wrote: I find that I can vaguely amusing 100% of the day and I love standup comedy... So I thought maybe I can give it a shot with a youtube channel? I already invent a cool personality - think Dirk Gently in computer science setting;) If that seems cool to you shoot me an email, or reply in this thread ... I need to the count to have a rough estimate of how low the size of my initial audience is.. Just to give you an example of my raw output... Are you not getting tired of this hopelessly boring OpenSource scene? All these 50 shades of JS framework, series. The long and dull re-runs of all of the web server framework shows. A clone of this! A copy of that but in Lua compiled to down to shell script. I hope the guys are giggling to themselves and this is all not serious in any way. Won't like to offend people, right? Wrong. I do not care really if something is fundamentally a copy I call it boring, despite it maybe have some interesting qualities. With that in mind I'd rather see people flex their brains on hard problems. Challenges! Just because the hardware is so fast you you can actually compile Lua to Shell script that transpiles itself to JavaScript starts the to show rainbows and ponies (with optional web assembly ray-tracing backend, that however is only supported on Chrome or Firefox, whatever). I'm talking about real work folks. Like how many interesting things can you pack in 32 bit machine word? Are you done making that list of yours? What about it being agnostic to Big / Little Endian issues when read from octet stream? Oh, gets more interesting doesn't it? How about adding a checksum of sorts, you know count the bits do some bitwise magic to validate the result in order to detect 1 bit of error creeping in during the transfer? How it looks if we print the octets as ASCII? Should keep my terminal settings intact at least when I pipe it in accidentally ... I could go on and on, but I'd prefer people to find the things they like the most obviously. Okay, it quickly gets out of hand and I need to get back to work I think.
[OT] What do you guys think of dark comedy channel on IT sh.. stuff?
I find that I can vaguely amusing 100% of the day and I love standup comedy... So I thought maybe I can give it a shot with a youtube channel? I already invent a cool personality - think Dirk Gently in computer science setting;) If that seems cool to you shoot me an email, or reply in this thread ... I need to the count to have a rough estimate of how low the size of my initial audience is..
Re: OT: Back
On Tuesday, 12 May 2020 at 07:21:43 UTC, Bastiaan Veelo wrote: On Tuesday, 5 May 2020 at 15:39:12 UTC, Dmitry Olshansky wrote: P.S. I'm kind of back, but very busy and my health is mostly great despite the COVID outrage out there. That's great! Glad to hear that. Bastian! Great to see you still around. How your D stuff is going at that naval company? -- Bastiaan.
[Meta] Lightweight Modular Staging library for D Language
Hi, folks Hope you are all safe at home with that virus outbreak world-wide. And it's good to be back. Being forced to lock down has it's ups and down. For one good aspect - I have found the time to re-implement and then (finally!) understand the beautiful meta programming technique called Lightweight Modular Staging by Martin Odersky et al. In a nutshell - late binding + staged computation == DI Framework. Which means that if you ever used DI framework you have worked and understood the basics of staged computation. Now if we add expression templates (or rather compile-time polymorphic expression trees) to the mix we what Martin calls Lightweight Modular Staging. I'm not sure where the modular part comes in but it's surely lightweight and powerful! So without further ado, I'm announcing the v1 of DLMS (LMS for D) library: Code: https://github.com/glow-stack/dlms DUB: https://code.dlang.org/packages/dlms There a few things that somehow fail at CTFE, I'll look into the workaround options, seems easy to fix though - the library is single ~350 LOC 0-deps D file. I think it's feature complete for the time being I might expand it as I move on to build the v2 of Pry parser generator using this LMS library as the backbone in particular exploiting the partial evaluation capabilities. Have fun and stay safe! -- Dmitry Olshansky
Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)
On Tuesday, 5 May 2020 at 21:41:39 UTC, Dmitry Olshansky wrote: On Tuesday, 5 May 2020 at 20:11:44 UTC, Robert M. Münch wrote: On 2020-05-05 15:39:12 +, Dmitry Olshansky said: On the other hand, if you can help someone to get started and it's a couple of hours, I would expect people to be fair enough and state: Hey, $400 (or whatever) is OK, let's take the rest to sponsor something else. That's what I would do. So here goes, indeed about 4.5 hours so far. The generator is untangled from the old crap from that GSOC 2012 repo: https://github.com/DmitryOlshansky/gen-uni-dlang PR: https://github.com/dlang/phobos/pull/7469 Let's see if the CI loves it or not.
Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)
On Tuesday, 5 May 2020 at 20:11:44 UTC, Robert M. Münch wrote: On 2020-05-05 15:39:12 +, Dmitry Olshansky said: On Monday, 4 May 2020 at 17:01:01 UTC, Robert M. Münch wrote: Following my "Is it time for a Unicode update of std.uni?" post in D group, I would like to try out to sponsor this effort for "Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)" [1] For me, this, too, is an experiment to find out if it's possible to move specific issues/topics forward. And maybe even find people that are open to contact work too. For me, all these things are pretty related. So, not knowing how much work it is, nor knowing what a good amount would be, I took the other route and asked me, what is it worth for me to get it done? Note: Getting #16416 done is not critical for me; most likely, I could even live with the current state of std.uni. On the other hand, std.uni is a very fundamental building block, and having it up to date and maybe even extended should be much value to D. So, I'm offering $750 to get it done. I'm guess I'm not eligible for the bounty ;) Why not? Felt a bit like cheating. Russian traditions preclude taking money for things you (think you) wanted to do anyway. Anyhow if anyone wants easy money - shoot me an email, or reply in this thread. Well, as I wrote, since I don't have a real good understanding about the necessary effort I started from "what is it worth for me in $ to get it done?". So, if it's a simple script-change and a re-run and you are the only one knowing this and keeping it for yourself... yes, it's easy money. On the other hand, if you can help someone to get started and it's a couple of hours, I would expect people to be fair enough and state: Hey, $400 (or whatever) is OK, let's take the rest to sponsor something else. That's what I would do. I started on it, and it turned out a bit more then I hope for + I'm doing it on simple Windows workstation without much of my usual power tools. LDC for Windows works like a charm though. It seems Unicode 13.0.0 pulled a plug on a couple of "derived" tables, that is data files that can be reconsturcted from other primary ones. Took at least half an hour to figure that out and rebuild the missing bits. If you don't mind I'll go with 100$ per hour estimate which is basically my usual contract rate. It took me about 2 hours for now, and I think I'd be done in a one or two more. Merging this into Phobos though is the otehr 90% of the legwork, I hope somebody will help me with that and maybe we'll just split your generous bounty this way. Spoiler is - the whole thing is code generated and there is only one table that I forgot about (i.e. I have no idea what is the source table for it in Unicode standard). With "forgot" you mean, you can't remember, or it's missing at all in your prior work? I mean I know what this table does by its usage but the codegen part is missing, likely a classic missing commit problem of being a single maintainer of the codegen tool (and the fact that it's not in the main dlang repos). P.S. I'm kind of back, but very busy and my health is mostly great despite the COVID outrage out there. That's great to hear... and maybe std.uni support/coaching for someone stepping up is possible. That would be great too. If, maybe even I can try to do it... Absolutely. I mean I'm in no shape to do the heavy lifting of day in day out maintanance of std.* stuff but I'd love to coach somebody to learn how std.regex and std.uni work. I can also share my vision for improvement, and will gladly help with refactoring. Both of modules predate many of the good things in DLang and std.allocator in particular. Boy, I'd love to have allocators back in the day. -- Dmitry Olshansky
Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)
On Monday, 4 May 2020 at 17:01:01 UTC, Robert M. Münch wrote: Following my "Is it time for a Unicode update of std.uni?" post in D group, I would like to try out to sponsor this effort for "Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)" [1] For me, this, too, is an experiment to find out if it's possible to move specific issues/topics forward. And maybe even find people that are open to contact work too. For me, all these things are pretty related. So, not knowing how much work it is, nor knowing what a good amount would be, I took the other route and asked me, what is it worth for me to get it done? Note: Getting #16416 done is not critical for me; most likely, I could even live with the current state of std.uni. On the other hand, std.uni is a very fundamental building block, and having it up to date and maybe even extended should be much value to D. So, I'm offering $750 to get it done. I'm guess I'm not eligible for the bounty ;) Besides getting the work done, there is one constraint: The work needs to get into Phobos. It doesn't make sense to have it sit around, because it's not being merged. I don't have any clue who is in charge, who decides this. Or if there need to be some conditions full-filled so that the result gets merged. Anyhow if anyone wants easy money - shoot me an email, or reply in this thread. Spoiler is - the whole thing is code generated and there is only one table that I forgot about (i.e. I have no idea what is the source table for it in Unicode standard). [1] https://issues.dlang.org/show_bug.cgi?id=16416 P.S. I'm kind of back, but very busy and my health is mostly great despite the COVID outrage out there. --- Dmitry Olshansky
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote: I never ever (I think) did something provocative, something to finally see: - who in the community WANTS D language to succeed? - who are just these funny “people” let’s call th this, that are I don’t know “just hang around” Because shame is a weapon much like fear (of death esp) And because I (of aaall people at least here, maybe I just don’t see others!) have no shame! I will roll on. You like the daily rant? Come get it! I have all the fucking bikering over say the merits(!) of say rstrip vs stripRight, right here - come take some, it’s fresh! Free even! Like how will these attempt to stop me look like? Pathetic, most likely but they will and we all we will have the good guys ( Atilla, this for you, man I swear WE will have fun and forums will be cool again)... So this C# pal comes and says like I offered him a drink with sandwich (for free!!) and he doesn’t like it - vegetarian(!). Okay: - I want async and await and async function and ALL of thay stuff from C# in D language ( I wait for a few moments to “compose” myself!) - So you want D to succeed (I mean C# is there and you seem to know it?) - Then how much effort (at least in theory, nit to mention that is an awful approach and we have Fibers, vibed, mecca and maybe soon Photon will roll!) does it take?! - Please let’s start with symbolic gesture, with plans like that a 1000$ is just a sign of goodwill right? P.S. I mean what you think the future of native code is??? Rust? Crystal?? Nim???
I have a plan.. I really DO
I never ever (I think) did something provocative, something to finally see: - who in the community WANTS D language to succeed? - who are just these funny “people” let’s call th this, that are I don’t know “just hang around” Because shame is a weapon much like fear (of death esp), pride can be used as weapon but ehm better shame the bastard... And so on. So - until we all understand that these donations are not because we are begging fir money. I will send ~ 10$ each day _specifically_ to see who WANTS D TO SUCCED and WILL NOT BE SHAMED LIKE THAT FOR ONCE! It is because it’s (soon) your last chance to invest into the Future. P.S. I mean what you think the future of native code is??? Rust? Crystal?? Nim???
Re: iopipe v0.1.0 - now with Windows support!
On Sunday, 17 June 2018 at 04:52:07 UTC, Martin Nowak wrote: On 06/10/2018 10:10 PM, Steven Schveighoffer wrote: Note that the new io library also supports sockets, which IODev did not have support for, AND has a pluggable driver system, so you could potentially use fiber-based async io without rebuilding. It just makes a lot of sense for D to have a standard low-level io library that everything can use without having to kludge together multiple types of io libraries. Note that the WIP std.io library is fully @nogc @safe, so it's a bit edgy on using latest features. Soon want to move to use DIP10008 instead of preallocated exceptions. This is very encouraging. I’d like to see it working well with Photon (though my time is very limited atm). Any thoughts on what set of syscalls I need to support? Maybe I could just provide my own “native” driver that fits your concept of I/O driver in io library. With that and @nogc in the Driver interface¹ it's still to be seen whether we can adapt this well with vibe.d or need to adjust the low-level design. -Martin ¹: https://martinnowak.github.io/io/std/io/driver/Driver.html
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 03:51:15 UTC, Anton Fediushin wrote: This is still just a rumour, we'll know the truth on Monday (which is today). Some articles about the topic: https://fossbytes.com/microsoft-github-aquisition-report/ https://www.theverge.com/2018/6/3/17422752/microsoft-github-acquisition-rumors What's your opinion about that? Will you continue using GitHub? Well, MS already contributes big time to many open-source projects, including Git. I do not see immanent problem with them buying it. Both GitLab and Bitbucket can be used instead to host your D projects - dub registry supported them for a while now. Both are fine, though Gitlab seems more sexy now. IMHO Microsoft isn't the type of company I want to see behind the GitHub. Maybe I am wrong since Microsoft has both money and programmers to improve it further, I just don't trust them too much which is the right thing to do when dealing with companies. Would you trust Google? Me, I’m not. In fact if we were to place trust, comercial IT companies would be pretty down on my list of “trust” in any case. This means that I will move my repositories elsewhere and use GitHub just to contribute to other projects.
Re: Looks like Digital Mars C++ is on the front page of HN at the moment!
On Wednesday, 23 May 2018 at 01:18:43 UTC, Walter Bright wrote: DigitalMars C/C++ Compiler (github.com) 56 points by tomcam 3 hours ago | unvote | flag | hide | 10 comments Yay! Any thoughts about opening runtime library? https://news.ycombinator.com/news And it’s beyond 100+ now. Also I see that you have quite a reputation in compilers ;)
Re: LDC 1.10.0 beta
On Sunday, 13 May 2018 at 18:12:51 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.10. The highlights of this version in a nutshell: * Based on D 2.080.0. * Supports DragonFly BSD. * Some fixes, most notably wrt. exception stack traces on Linux. Fantastic! And the time flies, wasn’t it 1.4 just recently? ;) Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.10.0-beta1 Thanks to all contributors!
Re: iopipe v0.0.4 - RingBuffers!
On Saturday, 12 May 2018 at 14:48:58 UTC, Joakim wrote: On Saturday, 12 May 2018 at 12:45:16 UTC, Dmitry Olshansky wrote: On Saturday, 12 May 2018 at 12:14:28 UTC, Steven Schveighoffer wrote: [...] I could offer a few tricks to fix that w/o getting too dirty. GNU grep is fast, but std.regex is faster then that in raw speed on a significant class of quite common patterns. But I loaded file at once. [...] As such initiative goes it’s either now or never. Please get in touch directly over Slack or smth, let’s make it roll. I wanted to do grep-like utility since 2012. Now at long last we have all the building blocks. If you're talking about writing a grep prototype in D, that's a great idea, especially for publicizing D. :) For shaming others to beat us using some other language. Making life better for everyone. Taking a DMD to a gun fight ;)
Re: iopipe v0.0.4 - RingBuffers!
On Saturday, 12 May 2018 at 12:14:28 UTC, Steven Schveighoffer wrote: On 5/11/18 5:42 PM, Joakim wrote: On Friday, 11 May 2018 at 16:07:26 UTC, Steven Schveighoffer wrote: [...] What stops you from downloading a linux release from here? https://github.com/ldc-developers/ldc/releases So I did that, it's not much faster, a few milliseconds. Still about half as fast as GNU grep. But I am not expecting any miracles here. GNU grep does pretty much everything it can to achieve performance -- including eschewing the standard library buffering system as I am doing. I can probably match the performance at some point, but I doubt it's worth worrying about. It's still really really fast without trying to do anything crazy. I could offer a few tricks to fix that w/o getting too dirty. GNU grep is fast, but std.regex is faster then that in raw speed on a significant class of quite common patterns. But I loaded file at once. I hope at some point, however, to work with Dmitry to add iopipe-based regex engine so we can see how much better we can make regex. As such initiative goes it’s either now or never. Please get in touch directly over Slack or smth, let’s make it roll. I wanted to do grep-like utility since 2012. Now at long last we have all the building blocks. -Steve
Re: iopipe v0.0.4 - RingBuffers!
On Friday, 11 May 2018 at 13:28:58 UTC, Steven Schveighoffer wrote: On 5/11/18 1:30 AM, Dmitry Olshansky wrote: On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer wrote: OK, so at dconf I spoke with a few very smart guys about how I can use mmap to make a zero-copy buffer. And I implemented this on the plane ride home. However, I am struggling to find a use case for this that showcases why you would want to use it. While it does work, and works beautifully, it doesn't show any measurable difference vs. the array allocated buffer that copies data when it needs to extend. I’d start with something clinicaly synthetic. Say your record size is exactly half of buffer + 1 byte. If you were to extend the size of buffer, it would amortize. Hm.. this wouldn't work, because the idea is to keep some of the buffer full. What will happen here is that the buffer will extend to be able to accomodate the extra byte, and then you are back to having less of the buffer full at once. Iopipe is not afraid to increase the buffer :) Then you cannot test it in such way. Basically: 16 Mb buffer fixed vs 16 Mb mmap-ed ring Where you read pieces in 8M+1 blocks.Yes, we are aiming to blow the CPU cache there. Otherwise CPU cache is so fast that ocasional copy is zilch, once we hit primary memory it’s not. Adjust sizes for your CPU. This isn't how it will work. The system looks at the buffer and says "oh, I can just read 8MB - 1 byte," which gives you 2 bytes less than you need. Then you need the extra 2 bytes, so it will increase the buffer to hold at least 2 records. I do get the point of having to go outside the cache. I'll look and see if maybe specifying a 1000 line context helps ;) Nope. Consider reading binary records where you know length in advance and skip over it w/o need to touch every byte. There it might help. If you touch every byte and do something the cost of copying the tail is zilch. One example is net string which is: 13,Hello, world! Basically length in ascii digits ‘,’ followed by tgat much UTF-8 codeunits. No decoding nessary. Torrent files use that I think, maybe other files. Is a nice example that avoids scans to find delimiters. Update: nope, still pretty much the same. The amount of work done per byte though has to be minimal to actually see anything. Right, this is another part of the problem -- if copying is so rare compared to the other operations, then the difference is going to be lost in the noise. What I have learned here is: 1. Ring buffers are really cool (I still love how it works) and perform as well as normal buffers This is also good. Normal ring buffers usually suck in speed department. 2. The use cases are much smaller than I thought 3. In most real-world applications, they are a wash, and not worth the OS tricks needed to use it. 4. iopipe makes testing with a different kind of buffer really easy, which was one of my original goals. So I'm glad that works! I'm going to (obviously) leave them there, hoping that someone finds a good use case, but I can say that my extreme excitement at getting it to work was depressed quite a bit when I found it didn't really gain much in terms of performance for the use cases I have been doing. Should be mostly trivial in fact. I mean our first designs for IOpipe is where I wanted regex to work with it. Basically - if we started a match, extend window until we get it or lose it. Then release up to the next point of potential start. I'm thinking it's even simpler than that. All matches are dead on a line break (it's how grep normally works), so you simply have to parse the lines and run each one via regex. What I don't know is how much it costs regex to startup and run on an individual line. It is malloc/free/addRange/removeRange for each call. I optimized 2.080 to reuse last recently used engine w/o these costs but I’ll have to check if it covers all cases. One thing I could do to amortize is keep 2N lines in the buffer, and run the regex on a whole context's worth of lines, then dump them all. I believe integrating iopipe awareness it in regex will easily make it 50% faster. A guestimate though. I don't get why grep is so bad at this, since it is supposedly grep on Mac is a piece of sheat, sadly and I don’t know why exactly (too old?). Use some 3-rd party thing like ‘sift’ written in Go. -Steve
Re: iopipe v0.0.4 - RingBuffers!
On Friday, 11 May 2018 at 09:55:10 UTC, Kagamin wrote: On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer wrote: However, I am struggling to find a use case for this that showcases why you would want to use it. While it does work, and works beautifully, it doesn't show any measurable difference vs. the array allocated buffer that copies data when it needs to extend. Depends on OS and hardware. I would expect mmap implementation to be slower as it reads file in chunks of 4kb and relies on page faults. It doesn’t. Instead it has a buffer mmaped twice side by side. Therefore you can avoid copy at the end when it wraps around. Otherwise it’s the same buffering as usual.
Re: iopipe v0.0.4 - RingBuffers!
On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer wrote: OK, so at dconf I spoke with a few very smart guys about how I can use mmap to make a zero-copy buffer. And I implemented this on the plane ride home. However, I am struggling to find a use case for this that showcases why you would want to use it. While it does work, and works beautifully, it doesn't show any measurable difference vs. the array allocated buffer that copies data when it needs to extend. I’d start with something clinicaly synthetic. Say your record size is exactly half of buffer + 1 byte. If you were to extend the size of buffer, it would amortize. Basically: 16 Mb buffer fixed vs 16 Mb mmap-ed ring Where you read pieces in 8M+1 blocks.Yes, we are aiming to blow the CPU cache there. Otherwise CPU cache is so fast that ocasional copy is zilch, once we hit primary memory it’s not. Adjust sizes for your CPU. The amount of work done per byte though has to be minimal to actually see anything. in the buffer. But alas, it's roughly the same, even with large number of lines for context (like 200). However, this example *does* show the power of iopipe -- it handles all flavors of unicode with one template function, is quite straightforward (though I want to abstract the line tracking code, that stuff is really tricky to get right). Oh, and it's roughly 10x faster than grep, and a bunch faster than fgrep, at least on my machine ;) I'm tempted to add regex processing to see if it still beats grep. Should be mostly trivial in fact. I mean our first designs for IOpipe is where I wanted regex to work with it. Basically - if we started a match, extend window until we get it or lose it. Then release up to the next point of potential start. Next up (when my bug fix for dmd is merged, see https://issues.dlang.org/show_bug.cgi?id=17968) I will be migrating iopipe to depend on https://github.com/MartinNowak/io, which should unlock Windows support (and I will add RingBuffer Windows support at that point). Enjoy! https://github.com/schveiguy/iopipe https://code.dlang.org/packages/iopipe http://schveiguy.github.io/iopipe/ -Steve
Re: serialport v1.0.0
On Sunday, 6 May 2018 at 22:02:05 UTC, Oleg B wrote: Stable version of serialport package * Blocking `SerialPortBlk` for classic usage * Non-blocking `SerialPortNonBlk` and `SerialPortFR` for usage in fibers or in vibe-d These 3 versions of the same API is precisely the reason for me starting the Photon project. Otherwise - great to see serial ports library and I'd be glad to one day test it for compatibility with my approach. * Variative initialization and configuration * Hardware flow control config flag Doc: http://serialport.dpldocs.info/v1.0.0/serialport.html Dub: http://code.dlang.org/packages/serialport Git: https://github.com/deviator/serialport
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Thursday, 12 April 2018 at 06:08:39 UTC, Kagamin wrote: On Wednesday, 11 April 2018 at 20:45:15 UTC, Dmitry Olshansky wrote: * Templates kind of muddy the waters being conpiled with the flags of caller (another reason why they are a mess). Meaning they will work with contracts if caller choses to have debug build. Template can call user code, but it wasn't tested for it, so the contract should be checked. What I mean is that for templates calling or not calling contracts depends on client code not the library. It’s just one consequence of template mechanism that has tons of other issues.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Friday, 6 April 2018 at 12:26:36 UTC, Mike Parker wrote: Congratulations to Zach Tollen and everyone who worked on DIP 1009. It took a painful amount of time to get it through the process, but it had finally come out of the other side with an approval. The proposal itself was approved early on, but it needed quite a bit of revision to get to an acceptable final draft. The DIP in its final form: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md What would have made contract trully powerful for me is them being emitted at caller side. This way if I use a release build of library but debugging my app I still get my stupidity guarded by contracts of the API. * Now *that* would be marvelous. Otherwise having a debug build for each of libraries just to check my precondition is too much of drag I’d say. After all libraries are typically stable code that are (presumably) debugged and you want them to be fast. * Templates kind of muddy the waters being conpiled with the flags of caller (another reason why they are a mess). Meaning they will work with contracts if caller choses to have debug build.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Wednesday, 28 March 2018 at 23:25:09 UTC, Walter Bright wrote: On 3/28/2018 1:27 PM, Jacob Carlborg wrote: There's usually nothing that prevents the build tool to write files at build time. Dub can do this. It's expected with a build tool. Not a compiler. With the frame of mind prevalent in our Industry I really want to have compiler includibg codegen as a bunch of library components. Then there is no problem innovating while people argue over things “allowed” for a compiler, or a linker, or a build tool. None of these actually have to be apps talking via files. If I look closely every program I see is a graph database, with nodes sometimes being code, types, sometimes data, other meta-data such as ABI attributes or conditional compilation flags, documentation, external tools, specs and databases are also part of this. Code that produces code is also part of such graph, and CTFE/macroses would just be finer grained approach. Why process graphs piece-wise in a frentic dance of command-line tools that try to fit all to a tree of files (multiple ones, in many location, and part in some CMS) and then have editors/IDEs integrate? Was easier I believe + inertia, easy != simple though.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Wednesday, 28 March 2018 at 23:29:28 UTC, Walter Bright wrote: On 3/28/2018 1:50 PM, Dmitry Olshansky wrote: Safety - not so much. I remember back in the olden dayz when Microsoft was pushing ActiveX controls hard. ActiveX controls were blobs of code automatically downloaded from the internet that were embedded in your spreadsheet, word document, etc. What could possibly go wrong? :-) I remember it... I even used some :) And it was efficient! But look at it today - many websites are basically a huge program running in a sandbox. And with more APIs they don’t need a particular page open to run in background and many other limitations are lifted. Still don’t understand why code signing became required on desktop, but not in the web.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote: On 3/27/2018 5:11 AM, Guillaume Piolat wrote: - ability to write file during CTFE is not necessarily positive. THough I can't tell why from the top of my mind. The act of compiling a buggy program not influence the global state of the computer. It should not be necessary to vet code downloaded from the internet before even compiling it to ensure it doesn't mess up the system. The moment there is make or other build tool this is all futile. CTFE should run in a sandbox. It must be safe to compile code. I agree but mostly on the grounds of purity and reproducibility. It also enables caching and incremental builds. Safety - not so much.
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On Thursday, 22 March 2018 at 10:59:56 UTC, Atila Neves wrote: Blog post: https://atilanevesoncode.wordpress.com/ Agreed on most counts though I’d say D simply produced a language without regard for build tools and large projects. Many small annoying things like version(unittest) stem from that fact. In addition I think many things could easily take a ton of time to compile and run tests. ctRegex is one such monster. Inadvertently pluging that into somebody else unittest build would be murder ;) It’s a given in some other languages that you need some library support to write tests (sometimes any tests) so they usually have cleancut prod dependecies and test dependencies. Our unitest being built-in practically forces the style. Atila
Re: Seeking lecturer - D language (Moscow)
On Monday, 19 March 2018 at 10:26:56 UTC, MGW wrote: Я работаю в Москве и вполне мог бы заняться этим направлением. Thanks! Replied in e-mail. On Friday, 16 March 2018 at 04:57:57 UTC, Dmitry Olshansky wrote: On Friday, 16 March 2018 at 00:18:20 UTC, Ivan Kazmenko wrote:
Re: The D Language Foundation at Open Collective
On Sunday, 18 March 2018 at 13:23:08 UTC, Dmitry Olshansky wrote: On Thursday, 15 March 2018 at 17:08:28 UTC, Ola Fosheim Grøstad wrote: On Thursday, 15 March 2018 at 17:06:00 UTC, Ola Fosheim Grøstad wrote: On Thursday, 15 March 2018 at 14:13:10 UTC, Mike Parker wrote: At the current exchange rate, a venti-sized cup of drip coffee at Starbucks in Korea is $4.51. When I go to GA, it's cheaper. A venti Americano is $4.79. But I think when people talk about $5 coffees, they're referring to lattes and all the other forms of polluted espresso abominations people drink. According to this article Russian Starbucks charge $12.30 for a latte... https://www.thespruce.com/how-much-is-starbucks-coffee-766065 Or actually, a tall cappuccino. Whatever. More like 6$ I’d say by looking at the actual price over here. Some facts for a change, the actual price list: PS: http://www.starbucks.ru/media/Цены%20на%20основные%20напитки_2018_01_tcm84-35742.pdf I do not see anything above ~300-400₽. Which is 5-6$.
Re: The D Language Foundation at Open Collective
On Thursday, 15 March 2018 at 17:08:28 UTC, Ola Fosheim Grøstad wrote: On Thursday, 15 March 2018 at 17:06:00 UTC, Ola Fosheim Grøstad wrote: On Thursday, 15 March 2018 at 14:13:10 UTC, Mike Parker wrote: At the current exchange rate, a venti-sized cup of drip coffee at Starbucks in Korea is $4.51. When I go to GA, it's cheaper. A venti Americano is $4.79. But I think when people talk about $5 coffees, they're referring to lattes and all the other forms of polluted espresso abominations people drink. According to this article Russian Starbucks charge $12.30 for a latte... https://www.thespruce.com/how-much-is-starbucks-coffee-766065 Or actually, a tall cappuccino. Whatever. More like 6$ I’d say by looking at the actual price over here.
Re: Vision document for H1 2018
On Friday, 16 March 2018 at 01:45:57 UTC, psychoticRabbit wrote:
On Thursday, 15 March 2018 at 18:39:08
public static class Utils
{
public static T[] Slice(this T[] arr, int start, int len)
{
T[] slice = new T[len];
Array.Copy(arr, start, slice, 0, len);
return slice;
}
}
Playing captain the obvious but this is COPY not slice. Slices in
D share underlying array, something that C# recently recognized
as special Span class that may point to GC heap or off-heap
memory.
D had slices since 2000s, pointing to any kind of memory.
Re: Seeking lecturer - D language (Moscow)
On Friday, 16 March 2018 at 00:18:20 UTC, Ivan Kazmenko wrote: On Wednesday, 14 March 2018 at 11:38:20 UTC, Dmitry Olshansky wrote: At the moment it’s a bit early stage but we are looking for enthusiast who has spare time and desire to spread the knowledge of D supremacy among students. The course will replace an equivalent of 1 year C++ course, but may start as half-year proof of concept. Sounds nice! Unfortunately, I won't be able to help in Moscow, but if the idea ever spreads to St. Petersburg, I'd definitely consider that. Which university it is now, by the way? Interestingly it’s Russian Goverment University for Humanities, but for their technical faculty. I've been exploring the possibility to use D in teaching at my uni (St. Petersburg State University), but didn't push it much, and got no result so far. The good folks that teach there are also part of my PhD advisor team. Basically they were fed up with troves of C++ lecturers who cannot grasp C++11 and the general misunderstanding with management: - “We should teach good, modern C++ instead of our C++ course” - “What do you mean - replace C++ with C++, what’s the point?” Hilarious thing but D has no identity problem like that ;) Ivan Kazmenko.
Re: Seeking lecturer - D language (Moscow)
On Wednesday, 14 March 2018 at 11:44:10 UTC, Simen Kjærås wrote: On Wednesday, 14 March 2018 at 11:38:20 UTC, Dmitry Olshansky wrote: - I owe you a bottle of your favorite beverage and your favorite bug in Bugzilla if you agree ;) https://issues.dlang.org/show_bug.cgi?id=5710 might be worth it, even if it means moving from friends and a comfy job in Norway... Ouch! I knew something like that will show up) Anyhow there is also posibility for remote ;) -- Simen
Seeking lecturer - D language (Moscow)
At the moment it’s a bit early stage but we are looking for enthusiast who has spare time and desire to spread the knowledge of D supremacy among students. The course will replace an equivalent of 1 year C++ course, but may start as half-year proof of concept. Facts: - 3h per week, scheedule can be easily adjusted but it should start within 8-17 hour range. - pay at Russian Universities is usually super low esp if not having Ph.D, so really it’s more of volonteer role - you don’t have to be professional lecturer, enthusiasm and desire to teach D is enough, you will have help of other senior folks - I owe you a bottle of your favorite beverage and your favorite bug in Bugzilla if you agree ;) - There is no hurry, it starts in September if all goes well. Contact me for details: dmitry.olsh at gmail.com — Dmitry Olshansky
OT: Miller’s 7+-2 “law”
On Saturday, 3 March 2018 at 16:59:56 UTC, Russel Winder wrote: On Sat, 2018-03-03 at 16:06 +, Dmitry Olshansky via DuckDuckGo search. It's a 1956 paper by Miller that claims 7 is the magic number for short term memory, the number of chunks of stuff you can keep for a certain period. A chunk is not a defined thing such as characters or words, but they are examples. I am not sure what the experimental status is of this "theory", but I suspect no-one has disproved it as yet. I know people who indirectly proved that theory to be correct in many unexpected ways. In particular when people are asked to define “distant” or “hot” as a set of classes they usually settle for around 7 states and cannot distinguish finer ones. Same problem with colors, as in defining shades of the same color. All that said, the trick is that ~7 applies to any “thing” and thusly your capacity increases if you can “merge” things to a single entity or otherwise establish relations or laws, doing reduction on a number of entities. Likely composition is a sideeffect of this tendency and 7 is not exact number in any wat.
Re: State of D 2018 Survey
On Saturday, 3 March 2018 at 15:52:02 UTC, Russel Winder wrote: On Sat, 2018-03-03 at 13:51 +, Dmitry Olshansky via Digitalmars-d- announce wrote: […] O.T.: Which is a well known number when it comes to cognition. It’s usually 7+-2. A number that is often misunderstood, and misused. As in this case. http://www.intropsych.com/ch06_memory/magical_number_seven.html Won’t load for me( Anyhow far as I can tell it is a measure of how many entities simultaniously you can hold in your attention, such objects in a picture frame. This doesn’t represent long-term memory or other capacities, which is likely the case here.
Re: State of D 2018 Survey
On Saturday, 3 March 2018 at 01:59:15 UTC, psychoticRabbit wrote: On Friday, 2 March 2018 at 12:20:31 UTC, Paulo Pinto wrote: And if you like C so much, what are you doing in a safe systems programming language forum? How safe is D.. i mean really ;-) and why do people ask me that question.. I don't get it. I program (or try to) in as many languages as my brain can handle ;-) Basically I hope you have goals or some system to pick these. (which oddly enough, seems to be stuck at about 7) O.T.: Which is a well known number when it comes to cognition. It’s usually 7+-2.
Re: D compiler daily downloads at an all-time high
On Monday, 12 February 2018 at 15:20:29 UTC, Martin Tschierschke wrote: On Monday, 16 November 2015 at 15:20:51 UTC, Andrei Congratulations to everybody who co Andrei Old post but new numbers! http://erdani.com/d/downloads.daily.png Would be nice to know what caused the recent spike to >8000? Are there any other usage stats available? For dlang.org or code.dlang.org ? Regards mt. When I see spikes like that out of nowhere that it’s usually some automation kicking in. Could it be a new CI that we didn’t account for yet? Secretly hope it’s a fresh wave of D users though ;)
Re: Vanquish Forever These Bugs That Blasted Your Kingdom
On Sunday, 11 February 2018 at 15:11:55 UTC, psychoticRabbit wrote: On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky wrote: Other languages like Rust or C# (or Java) have bounds check. Plus we probably lose it in release mode, which is the mode where lurking bugs are discovered usually days after development ;) Some of these languages would prevent it on the VM level/compiler level, leaving no way to shoot yourself in the foot. We all really need to get away from this idea that *we* should stop *others* from shooting themselves in the foot. People are free to do it, if they want. Who has the right to take that choice away from me? Your customers if you have any. Brcause they is inevitably you one day. So let's NOT be like those other languages that just want to control what you do. Then pick assembly of sorts. C ABI is a stright-jacket that ensures e.g. that your callstack is laid out correctly so that a ‘ret’ will bring you back to the call site not somewhere else. Do I need to mention libc’s machinations done “for compatibility”. Who the fuck were these guys to steal the pleasure of misaligned stacks and wrong push/pop order? Or register save missed? The reality is we are programming on top of increasingly complex run-times that solve low-level problems to certain extents. That includes C (even w/o libc) and pretty much any other high-level language. -boundscheck=off D rocks!
Re: Vanquish Forever These Bugs That Blasted Your Kingdom
On Wednesday, 7 February 2018 at 13:29:04 UTC, Mike Parker wrote: Walter's got a new post up! It's the first in a new series on the benefits of BetterC mode. In this one, he talks about solving the fencepost problem (off-by-one errors) with D's arrays. While an enjoable read, I fear we are aiming too low. Other languages like Rust or C# (or Java) have bounds check. Plus we probably lose it in release mode, which is the mode where lurking bugs are discovered usually days after development ;) Some of these languages would prevent it on the VM level/compiler level, leaving no way to shoot yourself in the foot. If we have bounds checks by default it looks silly to have pointer arithmetic enabled by default. It’s like “we are safe from this problem, as long as you write code using this primitive not the other one”, which is basically safety by convention.
Re: Vanquish Forever These Bugs That Blasted Your Kingdom
On Wednesday, 7 February 2018 at 13:29:04 UTC, Mike Parker wrote: Walter's got a new post up! It's the first in a new series on the benefits of BetterC mode. In this one, he talks about solving the fencepost problem (off-by-one errors) with D's arrays. Blog: https://dlang.org/blog/2018/02/07/vanquish-forever-these-bugs-that-blasted-your-kingdom/ DynamicArray is actually laid out in length, pointer order. Thankfully only reaaally low-level code has to know that. Reddit: https://www.reddit.com/r/programming/comments/7vw0gj/vanquish_forever_these_bugs_that_blasted_your/
Re: Another take on decimal data types
On Thursday, 11 January 2018 at 21:12:59 UTC, kdevel wrote:
On Thursday, 11 January 2018 at 20:40:01 UTC, Dmitry Olshansky
wrote:
printf ("%.2f\n", d);
C’s printf by definition can’t be customized.
Sure.
“”” GNU C Library lets you define “””
Here is your compatibility story.
What did you expect?
To be honest: A compile time error. Modern C compilers can
check such format strings. Example: GCC 6:
1. It’s a warning.
2. There is no typechecking it’s just a hardcoded linting in the
compiler.
3. It’s D use writefln or if going for C primitives know their
quirks.
4. Passing anything but basic types to C vararg is undefined in
C++ IIRC, dunno what D should do about it.
mis.c
```
#include
int main ()
{
double d = 0;
printf ("%p\n", d);
return 0;
}
```
$ gcc -Wall mis.c
mis.c: In function 'main':
mis.c:6:14: warning: format '%p' expects argument of type 'void
*', but argument 2 has type 'double' [-Wformat=]
printf ("%p\n", d);
Re: Another take on decimal data types
On Thursday, 11 January 2018 at 20:35:03 UTC, kdevel wrote:
Great project!
On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:
- all format specifiers implemented (%f, %e, %g, %a);
Really?
[...]
What's next:
- more tests;
Here you are:
```
import std.stdio;
import decimal;
void main ()
{
decimal32 d = "0.7";
d *= decimal32("1.05");
d.writeln;
printf ("%.2f\n", d);
C’s printf by definition can’t be customized. What did you expect?
float f = 0.7f;
f *= 1.05f;
f.writeln;
printf ("%.2f\n", f);
decimal32 e = 1_000_000_000;
while (e > 1e-7) {
e.writeln;
e /= 10;
}
}
```
This prints:
0.735
0.00 <--- expected: 0.74
0.735
0.73
<--- loop output missing
(DMD64 D Compiler v2.077.1)
Re: GSoC 2018 - Your project ideas
On Thursday, 7 December 2017 at 22:26:08 UTC, Bastiaan Veelo wrote: On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote: I am looking forward to hearing (1) what you think can be done in three months by a student and (2) will have a huge impact on the D ecosystem. [2] https://wiki.dlang.org/GSOC_2018_Ideas I see there is a dub section in [2]. Maybe another issue that has been brought up repeatedly fits in that category, namely extending code.dlang.org in various ways? + Indeed enhancing user experience of code.dlang.org such as showing github stars and e.g. downloads per month would be way more important then build tool itself.
Re: D User Survey
On Friday, 1 December 2017 at 18:56:50 UTC, WebFreak001 wrote: Hi everyone, I made a public survey (everyone can look at the responses) and it would be great if you took some time and answered it. I think it will greatly benefit D as a whole if we had more anonymous data on users. I'm also open for changing some questions if there is confusion. Truth be told I find survey largely irrelevant. What my gender or some such have to do with D? Or my job? What do we want to understand from that - “teenagers w/o like D language more?” or some such nonsense? I despise demographic style surveys, ask technical aspects instead, it would be 10x more informative. https://docs.google.com/forms/d/e/1FAIpQLSdPFx9ebHJ05QSW1VypBsQPw-1RbZ1v8FMgo1su6NvN6VErBw/viewform
Re: Intellij D Language v1.15.2
On Thursday, 23 November 2017 at 20:11:01 UTC, singingbush wrote: Hi all. A new release intellij-dlanguage plugin has been made available for download from the Jetbrains repository this week. The speed at which features and bug fixes are being done has picked up recently. We've had 4 releases this month alone. Then I think you guys should post on Annonce more often :) It would be really helpful if there are any Intellij users out there who don't already use our plugin to install it via the plugin repo and try it out (there are 2 D plugins, make sure to install the correct one). We now have error reporting built in to the plugin so that if anything breaks it's easy to inform the team about the problem. Awesome! Will give it a spin.
Re: Reorganization and list of D libraries (300+)
On Monday, 6 November 2017 at 16:59:52 UTC, jmh530 wrote: On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke wrote: Even being the wrong Martin :-) I think the DUB registry really needs more and better filters, so that the gems inside can be found easily. (like: Number of Github stars, number of downloads, number of developers and in the future: money donated to this project ...). There has been several attempts but I would like to encourage the D Foundation to put more focus on this. Better ecosystem around third party software means less work for improvement of standard lib. Regards mt. Agreed. (IMO more important than Elvis operator) +111
Re: Release D 2.077.0
On Saturday, 4 November 2017 at 08:19:17 UTC, Walter Bright wrote: On 11/3/2017 1:20 PM, Dmitry Olshansky wrote: Sadly array ops would be insufficient for said problem. It wasn’t a direct element wise expression. That sounds like that might be why it failed vectorization :-) As I recall it there were no trivial loops there. Usually these 2 magicians could make compiler eat it in a few hours of shuffling the code. They vectorized about half a dozen loops that way. The last one took 10 times more then the others taken together ;) If you recall the expression, it would be interesting to see it. Even if I had it saved somewhere the place was NDA-ed to death. I traded 3 months of intellectual work (and property) for a modest amount of money. Interesting experience but no illusions about R&D centers anymore.
Re: Release D 2.077.0
On Friday, 3 November 2017 at 19:46:58 UTC, Walter Bright wrote: On 11/3/2017 3:02 AM, Mike Parker wrote: For clarity, where the changeling says that GDC & LDC use auto-vectorization, that's actually happening with the array operations and core.simd is not required, correct? I think that GDC and LDC do do auto-vectorization, but I haven't verified it myself. Auto-vectorization is a fundamentally bizarre feature. It takes low level code and reverse-engineers it back into a higher level construct, and then proceeds to generate code for that higher level construct. Everything else a compiler does is start from a high level construct and then generate low level code. The trouble with AV is whether it succeeds or not depends on peculiarities (and I mean peculiarities) of the particular vector instruction set target. It can decided to not vectorize based on seemingly trivial and innocuous changes to the loop. I’ll share an anecdotal experience from a time I worked in reasearch lab of a well known tech giant. 2 senior researchers spent literally 2 weeks trying to coerce compiler into vectorizing an inner loop of a non-trivial matrix algorithm. The only diagnostic from compiler was “loop form is not correct”. Thankfully it did tell them it failed, else they’d have to disassemble it each time. I think eventually they either rewritten it to fit heuristic or just carried on with explicit intrinsics. What's needed is a language feature that is straightforwardly vectorizable. That would be D's array operations. Sadly array ops would be insufficient for said problem. It wasn’t a direct element wise expression.
Re: Caching D compiler - preview version
On Wednesday, 1 November 2017 at 19:33:15 UTC, Walter Bright wrote: On 10/29/2017 9:25 AM, Dmitry Olshansky wrote: On Saturday, 28 October 2017 at 23:18:05 UTC, Martin Nowak wrote: On 10/24/2017 05:02 PM, Dmitry Olshansky wrote: Experimental std.regex.v2 is sadly broken by a recent change to array ops. It would be very interesting to check as it eats up to 17Gb of RAM. What got broken there? New array ops implemented as __simd, I think it needs a __ctfe branch. Please post a bugzilla issue for it. https://issues.dlang.org/show_bug.cgi?id=17964
Re: SublimeLinter-contrib-dmd: dmd feedback as you type
On Monday, 30 October 2017 at 22:22:42 UTC, Bastiaan Veelo wrote: SublimeLinter-contrib-dmd [1] is a plug-in for the Sublime Text 3 editor [2]. [snip] The advantages of using dmd for linting are: 1. The parser is always up-to-date. 2. Full symbol resolution, including imports. 3. Mixins are expanded. 4. Templates are validated. 5. Deprecation warnings are included. 6. The "did you mean …" assistance appears right where it is most helpful. Sounds cool, I assume you use -o- option to disable DMD codegen? Should be fairly fast. [1] https://github.com/veelo/SublimeLinter-contrib-dmd [2] http://www.sublimetext.com/
Re: Caching D compiler - preview version
On Saturday, 28 October 2017 at 23:18:05 UTC, Martin Nowak wrote: On 10/24/2017 05:02 PM, Dmitry Olshansky wrote: Experimental std.regex.v2 is sadly broken by a recent change to array ops. It would be very interesting to check as it eats up to 17Gb of RAM. What got broken there? New array ops implemented as __simd, I think it needs a __ctfe branch.
Re: iopipe alpha 0.0.1 version
On Tuesday, 24 October 2017 at 19:05:02 UTC, Martin Nowak wrote:
On Tuesday, 24 October 2017 at 14:47:02 UTC, Steven
Schveighoffer wrote:
iopipe provides "infinite" lookahead, which is central to its
purpose. The trouble with bolting that on top of ranges, as
you said, is that we have to copy everything out of the range,
which necessarily buffers somehow (if it's efficient i/o), so
you are double buffering. iopipe's purpose is to get rid of
this unnecessary buffering. This is why it's a great fit for
being the *base* of a range.
In other words, if you want something to have optional
lookahead and range support, it's better to start out with an
extendable buffering type like an iopipe, and bolt ranges on
top, vs. the other way around.
Arguably this it is somewhat hacky to use a range as end marker
for slicing sth., but you'd get the same benefit, access to the
random buffer with zero-copying.
auto beg = rng.save; // save current position
auto end = rng.find("bla"); // lookahead using popFront
auto window = beg[0 .. end]; // get a random access window to
underlying buffer
I had a design like that except save returned a “mark” (not full
range) and there was a slice primitive. It even worked with
patched std.regex, but at a non-zero performance penalty.
I think that maintaining the illusion of a full copy of range
when you do “save” for buffered I/O stream is too costly. Because
a user can now legally advance both - you need to RC buffers
behind the scenes with separate “pointers” for each range that
effectively pin them.
So basically forward ranges with slicing.
At least that would require to extend all algorithms with
`extend` support, though likely you could have a small extender
proxy range for IOPipes.
Note that rng could be a wrapper around unbuffered IO reads.
Re: Caching D compiler - preview version
On Tuesday, 24 October 2017 at 14:17:32 UTC, Dmitry Olshansky wrote: On Tuesday, 24 October 2017 at 13:29:12 UTC, Mike Parker wrote: On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky wrote: What is dcache? It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern: Blog post or it didn't happen! Let us at least try it outside of toy examples. If anybody has std.regex.ctRegex usage I'd be curious to see: 1. Build time w/o -cache=mmap 2. First build time w -cache=mmap 3. Subsequent build times w -cache=mmap P.S. It's a crude PoC. I think we can do better. Another caveat: Posix-only for now. Did a few cleanups and widened the scope a bit. So here is what happens in my benchmark for std.regex. -O -inline -release: 88s --> 80s, memory use ~700Mb -> ~400Mb -release: 19s -> 12.8s Experimental std.regex.v2 is sadly broken by a recent change to array ops. It would be very interesting to check as it eats up to 17Gb of RAM.
Re: Caching D compiler - preview version
On Tuesday, 24 October 2017 at 13:29:12 UTC, Mike Parker wrote: On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky wrote: What is dcache? It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern: Blog post or it didn't happen! Let us at least try it outside of toy examples. If anybody has std.regex.ctRegex usage I'd be curious to see: 1. Build time w/o -cache=mmap 2. First build time w -cache=mmap 3. Subsequent build times w -cache=mmap P.S. It's a crude PoC. I think we can do better. --- Dmitry Olshansky
Caching D compiler - preview version
What is dcache? It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern: enum/static variable = func(args..); And if mangle of func indicates it is from std.* we use a cache to store D source code form of a result of function call (a literal) produced by CTFE. In action: https://github.com/dlang/dmd/pull/7239 (Watch as 2.8s - 4.4s to compile various ctRegex programs becomes constant ~1.0s.) Caching is done per expression so it stays active even after you change various parts of your files. Broadening the scope to 3rd party libraries is planned but cache invalidation is going to be tricky. Likewise there is a trove of things aside from CTFE that can be easily cached and shared across both parallel and sequental compiler invocations. Why caching compiler? It became apparent that CTFE computations could be quite time-consuming and memory intensive. The fact that each CTFE invocation depends on a set of constant arguments, makes it a perfect candidate for caching. Motivating example is ctRegex, patterns are hardly ever change and std.library changes only on compiler upgrade, yet each change to a file causes complete re-evaluation of all patterns in a module. With presistent per-expression cache we can precompile all of CTFE evluations for regexes, so we get to use ctRegex and maintain sane compile-times. How to use Pass new option to dmd: -cache=mmap This enables persistent cache using memory-mapped file. Future backends would take the form of e.g.: -cache=memcache:memcached.my.network:11211 Implementation Caveats emptor: this is alpha version, use at your own risk! https://github.com/DmitryOlshansky/dmd/tree/dcache Keeping things simple - it's a patch of around 200 SLOCs. I envision it becoming a hundred lines more if we get to do things cleanly. Instead of going with strangely popular idea of compilation servers I opted for simple distributed cache, as it doesn't require changing any of the build systems. Shared memory mapping split in 3 sections: Metadata (spinlock) + ToC (hash-table index) + Data (chunks) For now it's an immutable cache w/o eviction. A ToC entry is as follows: hash(64-bit), data index, data size, last_recent_use Indexes point to Data section of memory map. Data itself is a linked list of blocks, where a header contains: (isFree, next, 0-terminated key, padding to 16 bytes) last_recent_use is a ts of the start of the respective compilation. last_recent < now - 24h is considered unutilized and may be reused. In theory we can cache result of any compilation step with a proper key and invalidation strategy. 1. Lexing - key is compiler-version + abs path + timestamp, store as is. Lexing from cache is simply taking slices of memory. 2. Parsing to Ast - key is compiler-version + abs path + timestamp + version/debug flags 3. CTFE invocations - key is tricky, for now only enabled for std.* as follows: enum/static varname = func(args...); Use compiler-version + compiler-flags + mangleof + stringof args.
Re: iopipe alpha 0.0.1 version
On Monday, 16 October 2017 at 14:45:21 UTC, Steven Schveighoffer wrote: On 10/12/17 8:41 AM, Steven Schveighoffer wrote: On 10/12/17 1:48 AM, Dmitry Olshansky wrote: On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote: [...] Might be able to help you on that using WinAPI for I/O. (I assume bypassing libc is one of goals). That would be awesome! Yes, the idea is to avoid any "extra" buffering. So using CreateFile, ReadFile, etc. Dmitry hold off on this if you were going to do it. I have been looking at Jason White's io library, and think I'm going to just extract all the low-level types he has there as a basic io library, as they are fairly complete, and start from there. His library includes the ability to use Windows. Meh, not that I had mich spare time to actually do anything ;) Might help by reviewing what you have there. -Steve
Re: iopipe alpha 0.0.1 version
On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote: I added a tag for iopipe and added it to the dub registry so people can try it out. I didn't want to add it until I had fully documented and unittested it. http://code.dlang.org/packages/iopipe https://github.com/schveiguy/iopipe If you plan on using it, expect some API changes in the near future. I think the next step is really to add Windows support for the IODev type. Might be able to help you on that using WinAPI for I/O. (I assume bypassing libc is one of goals).
Re: DCompute OpenCL kernels now work
On Sunday, 8 October 2017 at 04:40:35 UTC, Nicholas Wilson wrote: I am happy to announce that DCompute will soon[1] support the OpenCL 2.1 runtime. I have tested it locally and it works now :) I wasted a good deal of time wondering why it wasn't and it was a small typo in DerelictCL trying to load OpenCL 2.2 symbols when loading 2.1. That along with OpenCL 2.x support for DerelictCL will be merged and tagged soon and then [1] can be merged. Most of the hard work is now done, leaving general polish and user feedback as the main development tasks. A unified driver abstracting over the CUDA and OpenCL drivers is on my todo list. https://github.com/libmir/dcompute/pull/36 This is awesome! I have some ambitious plans which depend on this development.
Re: Release D 2.075.0
On Saturday, 22 July 2017 at 21:22:00 UTC, Walter Bright wrote: On 7/22/2017 2:04 AM, Martin Nowak It'll be converted anyway. :-) Putting the entire set in D (C compiler, C++ compiler, C preprocessor, htod converter, optimizer, code generator) makes the whole thing much more tractable, and who knows what we will be able to do with it! Does that mean that DMC++ will hit Github? I'm also interested in open-sourced version of snn library, of course.
Re: Cap'n Proto for D v0.1.2
On 4/18/17 9:14 PM, Swoorup Joshi wrote: On Tuesday, 18 April 2017 at 18:09:54 UTC, Thomas Brix Larsen wrote: "Cap’n Proto is an insanely fast data interchange format and capability-based RPC system. Think JSON, except binary. Or think Protocol Buffers, except faster." This is the initial public release of my optimized port of the Java implementation of Cap'n Proto. State: * Passes Cap'n Proto testsuite. * Optimized. Just a little slower than the official C++ implementation (see benchmarks on github). * Missing RPC part of Cap'n Proto. http://code.dlang.org/packages/capnproto-dlang https://github.com/ThomasBrixLarsen/capnproto-dlang Java?? Yikes Risking a flamewar but what's wrong with Java? --- Dmitry Olshansky
Re: DConf 2017 Schedule
On 3/15/17 11:07 PM, Bastiaan Veelo wrote: On Wednesday, 15 March 2017 at 14:06:23 UTC, Yuxuan Shui wrote: So someone already wrote a parser combinator for D? I searched code.dlang.org (1.5 years ago?), and there was none, so I wasted couple weeks writing my own So, is yours on code.dlang.org? If it would have been, maybe Dmitry wouldn't have to waste his time. Anyway, Pegged definitely was there already. :-) The more the better ;) See you at dconf. --- Dmitry Olshansky
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
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
Re: A New Import Idiom`
On 2/14/17 3:32 AM, Jerry wrote: Anyways yes this is kind of cool and fascinating how it works, but that aside I hope I never see this used in phobos. Does anyone else feel this way? +1 Let's not make Phobos as scary as C++ STL. --- Dmitry Olshansky
Re: Questionnaire
On 2/11/17 5:04 AM, bachmeier wrote: On Friday, 10 February 2017 at 23:02:38 UTC, Dmitry Olshansky wrote: Go - they value simplicity and robust run-time (Go's GC breaks news with sub-milisecond pauses on large heaps). The sheer complexity of D is enough for it to be a hard sell, D's GC is coup de grace. I have never understood the appeal of Go. With respect to the GC, there's this: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.o6pxesvuw Has nothing new to say, yes GO's GC fragments heap, is slower at allocation and adds "read/write barriers from hell". But it does optimize for short pauses, which in turn avoids ugly spikes in server workloads and that is priceless. I have had the pleasure of trying to "tune away" the GC spikes of Java cluster software - it's not pleasant. With respect to "simplicity", I found it to be easy to learn a language that makes it hard to get stuff done. I've never understood the argument that programming in Go is simple. Clearly others have their own view. I agree with your view on this one. Go puts both advanced and novice programmers on the same ground - both have to write dumb code with little to no abstraction. In my limited time with Go I found it futile to abstract away even the most trivial patterns such as map-reduce with concurrency. --- Dmitry Olshansky
