Re: unit-threaded v0.7.45 - now with more fluency
On 05/08/2018 05:05 AM, Cym13 wrote: I wouldn't say it's an abuse, the dot means exactly the same thing as everywhere else in the language. No, it really doesn't mean the same thing at all. Not when you look away from the unimportant implementation details and towards the big picture: Normally, saying "x.y" denotes composition and membership: It means "y, which is a member of x". Saying "x.y" does NOT normally denote "The boundary between word 'x' and word 'y' in an english-grammared phrase". But with things like "should.not.be", it's very much NOT a composition/membership relationship: A "be" is not really a member/property/component/etc of a "not", except in the sense that that's how the english-like DSL is internally implemented. A "should" is not really something that is composed of a "not", except in the sense that that's how the english-like DSL is internally implemented. (IF it even is implemented that way at all. I didn't look, so for all I know it might be opDispatch.) I'm not saying that "should.not.be" OR "~" are abuses, I'm just saying whether or not they are, they're definitely both in the same category: Either they're both abuses or neither one is, because they both do the same thing: utilize use existing syntax for something other than the syntax's usual semantic meaning. Formal "operator overloading" isn't the only way to alter (or arguably abuse) a language's normal semantics.
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 18:44:06 UTC, Vladimir Panteleev wrote: On Tuesday, 8 May 2018 at 09:51:11 UTC, Mike Franklin wrote: I've been recently assigned the task of building a web-based Ladder Logic editor/compiler (https://en.wikipedia.org/wiki/Ladder_logic). This would not be a short-lived application, however. Hmm, sounds like this would be an interactive application that would need access to the HTML DOM. Currently, this isn't directly possible - when running in an asm.js VM, there is no D type to represent a JavaScript object. It is possible to call out to / eval JavaScript, though, so perhaps it could be possible using a shim, where a JavaScript array holds JavaScript/DOM objects, and D refers to them by index. Maybe we could port something like this to D. Or wait till someday dpp can #include the STL. https://github.com/mbasso/asm-dom/blob/master/README.md
Dioinformatic Challenges: Implement Needleman-Wunsch and Smith-Waterman algorithms
Hello D community. Just been back for a great Dconf2018. I got some feedback, and it took me some time to collect information and put the challenges here. As you may know, I posted these challenges in the "Learn" forum, but found out that it is better to post here in "announce". I am doing it for fun, for learning purpose, and for bringing up attention of D community to bioinformatics. It is not to hire and pay someone for their solutions. So, please don't mind if the amount of money for the prize is small to you:) A new deadline is also applied: 23:00 GMT+2, Saturday, 9 June 2018. That means we have about a month. Do your timing well and solve the challenges well :) Ask anything you need to know. Please see below for more details. Implement Needleman–Wunsch and Smith–Waterman algorithm ══ • Introduction about alignment problems: [http://bit.do/seqalign] (notes) and [http://bit.do/alignslides] (slides) or search on wikipedia. • Send zipped source code of the solution via email to "biocyberman at gmail dot com" with "DAC2018" in the subject line. • Implement in D. • See more details about these two challenges here: https://github.com/bioslaD/algorithms.bio/blob/master/dac2018/ChallengeGuide.md • Wining criteria: Combination of readability, reusability, scalability and speed • License: GPLv3. I will publish the solutions on Github. • Prize: USD100+ (more if others also want to sponsor?) for each problem (global or local aligment), sent via Papal. • Deadline: 23:00 GMT+2, Saturday, 9 June 2018.
Re: sumtype 0.3.0
On Tuesday, 8 May 2018 at 06:33:38 UTC, TheGag96 wrote: Wow.. without comments and unittests, the implementation is only 116 lines. Awesome job. Even now I still find it incredible what D can do. Is Algebraic in the standard library really that bad? And if so, why aren't implementations like this being accepted? Thanks! Algebraic isn't terrible, but it has one significant design flaw, which is that it shares its implementation with Variant. Variant doesn't have a fixed list of allowed types, so it requires a much more complex implementation than just a union and an integer tag. By sharing that implementation, Algebraic inherits all the costs of its complexity without getting any of the benefits. I've never contributed to Phobos, so someone with more experience may have better insight here, but my guess is that changing Algebraic at this point would break too much code to be worth the trouble. Perhaps when sumtype is more mature, though, a case could be made for including it in a separate module.
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 09:51:11 UTC, Mike Franklin wrote:
I've been recently assigned the task of building a web-based
Ladder Logic editor/compiler
(https://en.wikipedia.org/wiki/Ladder_logic). This would not be
a short-lived application, however.
Hmm, sounds like this would be an interactive application that
would need access to the HTML DOM. Currently, this isn't directly
possible - when running in an asm.js VM, there is no D type to
represent a JavaScript object. It is possible to call out to /
eval JavaScript, though, so perhaps it could be possible using a
shim, where a JavaScript array holds JavaScript/DOM objects, and
D refers to them by index.
I'm not sure if I would be much help with this, but know that
there is demand for it. I think the difficult part would be
porting the D runtime to "browser" environment, and I'm not
sure what's involved with that, especially given all platform
dependencies that the runtime is currently bound to.
Here are some of the challenges with getting D to run on
emscripten:
- Emscripten is neither Windows nor Posix, which causes most
version(platform){...}else... blocks to fail. Emscripten does
provide a libc (based on glibc, I think) which even abstracts
some things like I/O and the filesystem, but the feature set is
definitely less complete than the platforms we currently support,
so there's lots of stubbing involved.
- As a result of this, some parts of Phobos simply have no way of
working correctly. For example, a good part of std.math concerns
itself with the floating-point environment and flags, but in our
case these all come down to "whatever the browser gives you" -
which is probably standardized, but not under your control. So,
these definitions would need a version(dscripten){}else wrapper.
- In theory, garbage collection might be made to work, with
extensive help from the compiler. The problem is that we are
still using JavaScript's stack, which means we can't scan it for
pointers. It could be worked around by getting the compiler to
also place references to heap objects somewhere else, like a
second stack. For the short term, a practical approach would be
to use @nogc memory allocation / container libraries
(std.allocator etc.) and minimize GC allocations (e.g. closures
are still nice to have).
- Exceptions do not work - throwing simply aborts. C++ exceptions
do work in emscripten, so I think this could be made to work if a
compiler guru spends some time on it.
- Threads look like they could be made to work - emscripten seems
to have some wrappers to create/control Web Workers through a
libpthreads-like API.
Re: unit-threaded v0.7.45 - now with more fluency
On Tuesday, 8 May 2018 at 03:57:25 UTC, Johannes Loher wrote: Fluent assertions have one major advantage over using pascalCase assertions: There is no ambiuguity about the order of arguments. When using e.g. assertEquals, how do you know wheter is is supposed to be assertEquals(actual, expected), or assertEquals(expected, actual)? The first one is the only one that makes sense wirh UFCS, but it is not clear directly from the API. On top of that, some popular Frameworks (I‘m looking at you, JUnit...) do it exactly the other way round. With fluent assertions, you don‘t have this Problem, it is much more clear that it should be actual.should.equal(expected) and not expected.should.equal(actual), because it fits naturally in the chain of ufcs calls. Okay, I think I see your point, although it looks to me the added verbosity and code complexity is not really worth it, provided you always use UFCS. But of course, that cannot be easily enforced I guess.
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote: I heard there was a bit of general interest on the subject, so would be interesting to hear about more potential use cases. I've been recently assigned the task of building a web-based Ladder Logic editor/compiler (https://en.wikipedia.org/wiki/Ladder_logic). This would not be a short-lived application, however. I'd like to use D so I can take advantage of its fantastic modeling features to help manage the complexity of building such tool. It would also be more familiar, and therefore more productive, for me to use a language like D, so I don't have to do so much study and figuring to implement my ideas in Javascript, or learn some new API/framework/library/tool/whatever. One of my primary motivations for learning D is to avoid having to learn a different programming language for every different platform or problem domain: modeling power, modern convenience, and native efficiency are the trifecta for me (we should have kept that motto, IMO). Add some platform independence, and I'm extremely happy. For now, unfortunately, it looks like I'll probably be using primarily Javascript and C#. I'm not sure if I would be much help with this, but know that there is demand for it. I think the difficult part would be porting the D runtime to "browser" environment, and I'm not sure what's involved with that, especially given all platform dependencies that the runtime is currently bound to. Mike
Re: unit-threaded v0.7.45 - now with more fluency
On Tuesday, 8 May 2018 at 07:07:30 UTC, Nick Sabalausky (Abscissa) wrote: On 05/07/2018 11:57 PM, Johannes Loher wrote: On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote: I think I'm siding with Johannes here. Much as the overloads look nice, I don't really see the advantage over `shouldEqual`. Also, what's with `all.these.identifiers`? Any particular reason why you are more fond of them rather than of good ol' pascalCase? Fluent assertions have one major advantage over using pascalCase assertions: There is no ambiuguity about the order of arguments. When using e.g. assertEquals, how do you know wheter is is supposed to be assertEquals(actual, expected), or assertEquals(expected, actual)? The first one is the only one that makes sense wirh UFCS, but it is not clear directly from the API. On top of that, some popular Frameworks (I‘m looking at you, JUnit...) do it exactly the other way round. With fluent assertions, you don‘t have this Problem, it is much more clear that it should be actual.should.equal(expected) and not expected.should.equal(actual), because it fits naturally in the chain of ufcs calls. I don't think that's the issue. At least, it isn't for me. It's not a question of "assert equals" vs "should equal" (Though I am convinced by your argument on that matter). The question is: Why "should.equal" instead of "shouldEqual"? The dot only seems there to be cute. Not that I'm necessarily opposed to any of it (heck, I like cuteness in any sense of the word), it's just that: If the "~" thing is operator abuse, then I don't see how "should.equal", "should.not.be" etc, wouldn't fall into the same category. I wouldn't say it's an abuse, the dot means exactly the same thing as everywhere else in the language. I'm way less fan of overidding ~ since that doesn't have that meaning in any other context. Without having actually used it, I like the composability over pascalCasing here, it looks like it fits nicely in a functional environment with things like aliases and partials I think, defining your own primitives naturally... Nothing one can't do with regular functions and pascalCased assertions, but it sounds like it would be way more verbose. It also sounds like it's easier on the implementation side since you never have to define both a "shouldSomething" and "shouldNotSomething", and that means as a user I can expect less bugs and better maintainance of the library. That said, it'll have to be field-tested to be sure.
A bit more Emscripten
https://github.com/CyberShadow/dscripten-tools This builds a little upon Sebastien Alaiwan (Ace17)'s excellent prior work of putting together a toolchain for compiling D to JavaScript / asm.js. Improvements include a DMD-like driver and rdmd wrapper, meaning that most tools that know how to use dmd/rdmd will be able to also use this toolchain. Dub is an example. Currently the focus is on headless scripts - Web Workers and Node. Also included are some hacked up parts of Phobos/Druntime. Generally such environments are restricted to @nogc stuff, but I wanted to see how far we can get without prior restrictions. As a result, things like Appender and format(...) (i.e. formatting to the heap) work. Of course, garbage collection is unavailable - it's using the "manual" GC implementation (allocates only), though considering most webpages are short-lived, it might not be a problem for many use cases. I heard there was a bit of general interest on the subject, so would be interesting to hear about more potential use cases.
Re: Funding for code-d/serve-d
On Tuesday, 8 May 2018 at 05:53:43 UTC, Apocalypto wrote: On Monday, 7 May 2018 at 09:29:06 UTC, Dechcaudron wrote: Also, though I use WebFreak's extension for VS code, I never really got it to work 100% (never really invested more than a couple minutes either, to be fair). Thinks like syntax highlighting and symbol lookup are really welcome, but I'd like completion support out of the box. Is it only me that has an issue with this? You are not the only one. I'll stick to VisualD for the moment on Windows, especially for debugging experience. #meetoo
Re: sumtype 0.3.0
On 05/07/2018 05:35 PM, Paul Backus wrote:
Personally, I consider [pattern matching] an essential
feature--arguably *the* essential feature--
After having used Nemerle, I tend to agree.
I haven't gotten around to using this yet, but I did take a look at the
source and was blown away by how small and simple it is. Kudos!
Oh, and I love that it's much easier to remember how to spell than
"Algebraic" :)
That said, it would be really nice if D made it possible for a tool like
this to support more things being defined in-line. For example, in
Nemerle, it's possible to define a binary tree like this:
-
// Mainly from:
// https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching
variant Tree {
| Node {
left : Tree;
elem : int;
right : Tree;
}
| EmptyLeaf
}
-
But AFAIK, in D, each part would have to be defined separately, making
the overall structure less clear:
-
struct Node {
Tree* left;
int elem;
Tree* right;
}
struct EmptyLeaf {}
alias Tree = SumType!(Node, EmptyLeaf);
-
Of course, that's not your lib's fault, just an unfortunate limitation of D.
Re: unit-threaded v0.7.45 - now with more fluency
On 05/07/2018 11:57 PM, Johannes Loher wrote: On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote: I think I'm siding with Johannes here. Much as the overloads look nice, I don't really see the advantage over `shouldEqual`. Also, what's with `all.these.identifiers`? Any particular reason why you are more fond of them rather than of good ol' pascalCase? Fluent assertions have one major advantage over using pascalCase assertions: There is no ambiuguity about the order of arguments. When using e.g. assertEquals, how do you know wheter is is supposed to be assertEquals(actual, expected), or assertEquals(expected, actual)? The first one is the only one that makes sense wirh UFCS, but it is not clear directly from the API. On top of that, some popular Frameworks (I‘m looking at you, JUnit...) do it exactly the other way round. With fluent assertions, you don‘t have this Problem, it is much more clear that it should be actual.should.equal(expected) and not expected.should.equal(actual), because it fits naturally in the chain of ufcs calls. I don't think that's the issue. At least, it isn't for me. It's not a question of "assert equals" vs "should equal" (Though I am convinced by your argument on that matter). The question is: Why "should.equal" instead of "shouldEqual"? The dot only seems there to be cute. Not that I'm necessarily opposed to any of it (heck, I like cuteness in any sense of the word), it's just that: If the "~" thing is operator abuse, then I don't see how "should.equal", "should.not.be" etc, wouldn't fall into the same category.
