Guillaume Piolat wrote:
Any input concerning stb_vorbis vs Tremor? Tremor is twice the code size
and I'm not sure the one to be favoured.
tbh, i didn't really tested stb much (if at all). it *should* work, but...
my audio player was based on tremor, so it is better tested. maybe just
make
Guillaume Piolat wrote:
On Wednesday, 18 March 2020 at 18:49:23 UTC, ketmar wrote:
glad you found it useful! but why only that? there is GPL Opus decoder
too, and two decoders for Ogg/Vorbis: stb and complete port of the
official Xyph tremor library. also, you can find a resampler there,
Guillaume Piolat wrote:
On Wednesday, 18 March 2020 at 18:41:11 UTC, Guillaume Piolat wrote:
audio-formats is a new pure D #DUB package that allows to decode and
encode audio files.
Also: it's just a custom repackaging of the huge work of Ketmar.
https://repo.or.cz/iv.d.git
glad you
Adam D. Ruppe wrote:
On Friday, 22 November 2019 at 03:42:26 UTC, dokutoku wrote:
Is there a difference in the execution speed and stability when
executing the program by rewriting the parameter of the function
argument like this?
the generated code the processor sees is generally
Adam D. Ruppe wrote:
I am bumping the arsd repo dub's version number to 4.0.0. (this is super
super arbitrary for me though, I very rarely ACTUALLY break backward
compatibility, in fact I try to be both backward and forward compatible
with myself and with dmd versions, just meh)
yay, so
H. S. Teoh wrote:
actually, there is a 3rd issue, which is often overlooked: conversion
from string to float. to get a perfect roundtrip, this one should be
done right too.
Doesn't hex output format (e.g. std.format's %a and %A) already solve
this? It basically outputs the exact bits in hex.
Basile B. wrote:
On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote:
too bad that i didn't knew about Ryu back than.
It's very recent, announce on proggit is < 1 year.
It would be nice to have one to format in phobos. RYU or Grisu3 doesn't
matter much as long as the two issues that
i think that porting Ryu will get us the fastest one (and with
smaller/easier code). and without pathological cases of grisu too. too bad
that i didn't knew about Ryu back than.
as for roundtrips -- you're probably right. stb implementation was made to
be "mostly correct", afair, but not
Stefan Koch wrote:
Hi Guys,
during my research on floating point numbers I came across a short and
efficient implementation[0] of the grisu2 algorithm for converting
floating point numbers into strings.
Which I then ported into CTFEable D code.
Thus enabling you to convert doubles into
Guillaume Lathoud wrote:
this is UB. by the specs, values are promoted to int, and shifting int by
50 is UB. so both results are nonsense.
vit wrote:
thanks, that code can be modified to pure nothrow @nogc @safe.
Is that lib ok? Is little complicated...
converting float to string is a *very* complicated task. that lib is quite
small for what it is doing ('cause it hacks around some... interesting
cases). the *real* thing will
vit wrote:
Hello, is in phobos some function which convert float/double to string
and is pure @nogc and nothrow?
i don't think that you can make it `pure`, but you certainly can make it
`nothrow`, `@nogc` and ctfe-able. it's dangerous to go alone! take this[0].
[0]
Johan Engelen wrote:
On Friday, 13 July 2018 at 14:51:17 UTC, ketmar wrote:
yeah. in simple words: safe code is *predictable*, but not
"segfault-less". segfaults (null dereferences) in safe code are allowed,
'cause they have completely predictable behavior (instant program
termination).
Johan Engelen wrote:
On Friday, 13 July 2018 at 14:51:17 UTC, ketmar wrote:
yeah. in simple words: safe code is *predictable*, but not
"segfault-less". segfaults (null dereferences) in safe code are allowed,
'cause they have completely predictable behavior (instant program
termination).
Steven Schveighoffer wrote:
To emphasize the point, this is @safe as well:
X2 x2; // = null
x2.run();
D does not consider a segmentation fault due to null dereferencing to be
unsafe -- no memory corruption happens.
yeah. in simple words: safe code is *predictable*, but not "segfault-less".
Piotr Mitana wrote:
This code:
import std.stdio;
class X1 {}
class X2 : X1
{
void run() @safe
{
writeln("DONE");
}
}
void main() @safe
{
X1 x1 = new X1;
X2 x2 = cast(X2) x1;
x2.run();
}
Basile B. wrote:
On Sunday, 1 July 2018 at 15:03:30 UTC, ketmar wrote:
Basile B. wrote:
I've recently ported libfirm to D.
great news and great work, thank you. yet i must admit that wrapping !=
porting.
Right, i have used the wrong words. Title hopefully is not ambiguous.
ah, tbh,
Basile B. wrote:
On Sunday, 1 July 2018 at 15:03:30 UTC, ketmar wrote:
Basile B. wrote:
I've recently ported libfirm to D.
great news and great work, thank you. yet i must admit that wrapping !=
porting. for a moment you made my heart stopped, 'cause i thought that i
wasted alot of time
Basile B. wrote:
I've recently ported libfirm to D.
great news and great work, thank you. yet i must admit that wrapping !=
porting. for a moment you made my heart stopped, 'cause i thought that i
wasted alot of time trying to do a proper port (nope, not finished, but still...).
Andrea Fontana wrote:
I hope I'm wrong. Maybe I'm missing something. Anyone can help?
you are not wrong, this is bug in DMDFE.
Steven Schveighoffer wrote:
Can you put in some more debug messages and see what the exact types of A
and T are? Just put it right before the assert.
you prolly asked Russel here, as i don't have his sources to experiment
with. ;-)
Russel Winder wrote:
On Fri, 2018-06-01 at 17:53 +0300, ketmar via Digitalmars-d-learn
wrote:
[…]
it looks like "// type T is not constructible from A" phobos
assertion triggered. that is, std.variant cannot wrap the struct, and
all hell
breaks loose.
An instance of Fronte
Russel Winder wrote:
On Fri, 2018-06-01 at 16:37 +0300, ketmar via Digitalmars-d-learn
wrote:
[…]
yeah. if it receives something it doesn't expect (and there is no
`Variant` clause to catch it), it throws. and exceptions from threads are
silently dropped on the floor -- along with the dead
Steven Schveighoffer wrote:
On 6/1/18 7:12 AM, Russel Winder wrote:
So I had a play and gdb seems to be useless for trying to find out why
calls to std.concurrency.receive exit silently.
Obviously std.concurrency.receive should never terminate a thread, and
it should never terminate a thread
H. S. Teoh wrote:
p.s. and struct with `alias this` will allow us to extend it with fields
too. not without using some other tricks, of course, but as there is a
documented and ligitimate way to workaround any "sealing", i myself see a
little sense in such feature. the only thing it will be
H. S. Teoh wrote:
On Fri, May 11, 2018 at 05:28:48PM -0600, Jonathan M Davis via
Digitalmars-d wrote:
[...] what the OP wants is to have the class be publicly available
while restricting who's allowed to derive from it, with the idea that
a particular class hierarchy would have a well-defined
Basile B. wrote:
I hadn't announced the 5 or 6 latest releases (3.6.x series) but this one
comes with an integrated terminal emulator (linux only), a bit like Geany
does, if you see what i mean.
See https://github.com/BBasile/Coedit/releases for changelog and download
links.
yay!
Kayomn wrote:
I'll give a better example of what it is I'm trying to do.
These are node types. Their contents are not important in this
explanation, only that they operate as a tree structure.
class Node;
class RootNode : Node;
class SpriteNode : Node;
The result of getNodeID on a
Laurent Tréguier wrote:
On Friday, 30 March 2018 at 11:04:59 UTC, ketmar wrote:
p.s.: still, it may be nice to warn user about that. 'cause such runtime
initializations are really belong to static ctor. dunno, i'm ok both
with warning and without it.
I simply think a word about it in the
p.s.: still, it may be nice to warn user about that. 'cause such runtime
initializations are really belong to static ctor. dunno, i'm ok both with
warning and without it.
Laurent Tréguier wrote:
Is this behavior really intentional ?
yes. default values should be the same for all objects. it is predictable,
and allows to initialize objects to the known state simply by blitting
`.init`.
that is, default values aren't a syntax sugar for defining implicit ctor
Martin Tschierschke wrote:
or tutorial
ok, tutorial:
1. learn C.
2. learn D.
3. DO IT!
;-)
Nicholas Wilson wrote:
On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:
What is so hard about implementing a pow intrinsic that CTFE can use?
It's ridiculous that we can't CTFE any non-linear function...
It's one of those blocker bugs that's been there almost 10 years.
Not all that
Manu wrote:
What is so hard about implementing a pow intrinsic that CTFE can use?
It's ridiculous that we can't CTFE any non-linear function...
It's one of those blocker bugs that's been there almost 10 years.
nobody bothered. it is all done by intercepting calls in CTFE engine (using
FQN
Miguel L wrote:
as the calculations on f guarantee it cannot be 0 at all.
than `f` will become zero very soon. something that "cannot happen" is the
most probable thing to happen.
otherwise, LGTM.
psychoticRabbit wrote:
Whatever happened to the 'discussion' component of these 'discussions'?
dunno. try to ask yourself, why repeating the same point again and again
when you were given the answer and the rationale doesn't make a good
discussion.
psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:25:39 UTC, ketmar wrote:
psychoticRabbit wrote:
So the 3 most used languages got it wrong??
yes.
do you know any other language, where a private class memeber, is not
private to the class?
(btw. that's a question, not a
psychoticRabbit wrote:
So the 3 most used languages got it wrong??
yes.
psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote:
psychoticRabbit wrote:
There are two problems I see:
1) it is not how C++ done it.
2) it is not how C++ done it.
and you're completely right: it is not how C++ done it.
umm...didn't you forget something:
1)
psychoticRabbit wrote:
There are two problems I see:
1) it is not how C++ done it.
2) it is not how C++ done it.
and you're completely right: it is not how C++ done it.
psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote:
private is private to the module, not the class. There is no way in D to
restrict the rest of the module from accessing the members of a class.
This simplification makes it so that stuff like C++'s
Adam D. Ruppe wrote:
compiler used to build the compiler... if i try to just build dmd from
git i get
`/home/me/d/dmd2/linux/bin32/../../src/druntime/import/core/exception.d(686):
_store is thread local`)
it is just a -vtls message, btw, absolutely harmless. i don't know why that
reporting
Seb wrote:
Out of interest: Why would you compile the compiler from the release
sources? After all, it's the binary release bundle and not the
development build. Also there are tools like digger that automate
everything for you...
I understand that sometimes it can be nice to do that, but
Nick Sabalausky (Abscissa) wrote:
(Or does return the address of the *reference* to the object
rather than the address of the object?...You can see just how often I do
OO in D ;) )
exactly. if you want to convert object to a pointer safely, do this:
MyObject o;
void* p =
Nick Sabalausky (Abscissa) wrote:
I'm having trouble finding the documentation for what exactly the unary
"not" operator does when applied to a class/interface object. Does this
documentation exist somewhere?
I know at least part of it involves "is null", but I seem to remember
hearing
H. S. Teoh wrote:
I've pestered Brad about it before, but the real trouble is the Mailman
software. If you feel motivated enough, pestering the upstream Mailman
authors about it might actually get us closer to fixing this problem, as
it really isn't a problem on Brad's end either. It's not
Seb wrote:
OT: I don't know what you are doing, but you seem to be the only one who
always creates new threads when replying. I assume you use nntp? Maybe
something wrong with your client?
it was already discussed several times: this is the issue with mailing list
processor: it cannot
Matt Gamble wrote:
Ok, this has been submitted as a bug.
https://issues.dlang.org/show_bug.cgi?id=18573
thank you.
Matt Gamble wrote:
On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /*
H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn
wrote:
[...]
it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it does
H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn
wrote:
[...]
it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it does
Steven Schveighoffer wrote:
it seems that the only difference between `void` and `double` lambda is one
asm instruction: `fldl (%edi)`. it is presend in `double` labmda, and
absent in `void` lambda.
it looks like ignoring `double` result causes FPU stack imbalance ('cause
compiler doesn't
Martin Tschierschke wrote:
basically, compilation of a code without templates is FAST. 500+ KB of
source almost without templates often compiles in less than a second (on
not-so-bleeding-edge i3, not even i7).
but throw templates in a mix, and BOOM! coffee and cigarettes.
My negative
aliak wrote:
On Monday, 26 February 2018 at 21:34:21 UTC, ketmar wrote:
aliak wrote:
And if that's also a no no, how about char -> int. Or int -> float? Is
ok?
no, it is not ok. it was a mistake. it is now too late to fix it, but we
can avoid doing more of the same kind.
Oops, yeah, ok,
Martin Tschierschke wrote:
On Tuesday, 27 February 2018 at 08:49:15 UTC, Stefan Koch wrote:
On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote:
H. S. Teoh wrote:
On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d
wrote:
[...]
When looking at the problem
H. S. Teoh wrote:
On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote:
[...]
but until that brave new world materializes, we have a smart/fast
dilemma. alas.
I'd like to contribute to the materialization of that brave new world.
Rather than sit around and wait
aliak wrote:
It makes libraries *much* more intuitive and expressive (C++ just got it
wrong by choosing the wrong default). If you allow library authors to opt
in instead of opt out then it becomes a conscious decision for one.
library authors can create overloads for various argument types.
aliak wrote:
And if that's also a no no, how about char -> int. Or int -> float? Is ok?
no, it is not ok. it was a mistake. it is now too late to fix it, but we
can avoid doing more of the same kind.
Kayomn wrote:
On Monday, 26 February 2018 at 21:04:51 UTC, TheFlyingFiddle wrote:
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
[...]
Don't think you can alias member variables directly.
You could do this though:
struct Player {
Entity entity;
ref auto pos() inout {
H. S. Teoh wrote:
The problem is not the Phobos implementation. The problem is that the
compiler's way of handling templates and CTFE needs to be improved. We
seriously need to muster some manpower to help Stefan finish newCTFE,
and then we need to take a serious look at improving the current
WebFreak001 wrote:
Now before you would have only been able to do this:
---
Nullable!Foo a;
foo(a, Nullable!int(5));
---
but now you should also be able to do:
---
Nullable!Foo x = null;
Nullable!Foo y = 5;
foo(null, 5);
please no. such unobvious type conversions goes out of control
H. S. Teoh wrote:
On Mon, Feb 26, 2018 at 08:38:39PM +0200, ketmar via Digitalmars-d wrote:
H. S. Teoh wrote:
On Sat, Feb 24, 2018 at 09:43:35AM +, Stefan Koch via Digitalmars-d
wrote:
[...]
This particular slowdown happens because there are somehow
depdencies on std.format.format which
H. S. Teoh wrote:
On Sat, Feb 24, 2018 at 09:43:35AM +, Stefan Koch via Digitalmars-d
wrote:
[...]
This particular slowdown happens because there are somehow depdencies
on std.format.format which is instantiated.
Which has a ton of dependencies itself.
Aha! That explains it. Thanks,
H. S. Teoh wrote:
On Sat, Feb 24, 2018 at 09:43:35AM +, Stefan Koch via Digitalmars-d
wrote:
[...]
This particular slowdown happens because there are somehow depdencies
on std.format.format which is instantiated.
Which has a ton of dependencies itself.
Aha! That explains it. Thanks,
H. S. Teoh wrote:
On Sat, Feb 24, 2018 at 09:43:35AM +, Stefan Koch via Digitalmars-d
wrote:
[...]
This particular slowdown happens because there are somehow depdencies
on std.format.format which is instantiated.
Which has a ton of dependencies itself.
Aha! That explains it. Thanks,
H. S. Teoh wrote:
On Mon, Feb 26, 2018 at 08:07:11PM +0200, ketmar via Digitalmars-d wrote:
[...]
in C, arrays are *always* decaying to pointers. so
void foo (int x[2])
is the same as
void foo (int* x)
`[2]` is purely informational.
that is, in D it will be:
alias
H. S. Teoh wrote:
What's the correct translation of the following C declarations into D?
typedef double[1] mytype;
void someFunc(mytype x, mytype *y, mytype **z);
struct SomeStruct {
mytype x;
mytype *y;
mytype **z;
works for me with 2.076.
add postblit debug prints, and you will see.
JN wrote:
same idea?
absolutely the same. non-qualified imports (be it template, or function)
won't take part in overload resoultion.
JN wrote:
Is this expected behaviour?
bar.d
---
void foo(string s)
{
}
app.d
---
import std.stdio;
import bar;
void foo(int x)
{
}
void main()
{
foo("hi");
};
===
Error: function app.foo (int x) is not callable using argument types
(string)
yes. this is done so unqualified won't
Nick Sabalausky (Abscissa) wrote:
Are there any tutorials or articles out there for "getting started with
converting a C++ codebase to D one module at a time?" Or at the very
least: tips, tricks, lessions learned, from those who have come before.
from my experience (various codebases up to
Jiyan wrote:
Hi :),
What i thought was that when i create a struct dynamically i can just
deconstruct it with __dtor lets say:
struct U {...}
struct S {... private U _member;}
S* p;
p = cast(S*)malloc(S.sizeof);
// just run that if it compiles, for simplicity
// we dont use
0x wrote:
On Wednesday, 21 February 2018 at 09:21:58 UTC, 0x wrote:
What is the equivalent of C++17 std::string_view (an object that can
refer to a constant contiguous sequence of char-like objects with the
first element of the sequence at position zero) in D?
PS: I'm
psychoticRabbit wrote:
On Tuesday, 20 February 2018 at 12:18:47 UTC, rikki cattermole wrote:
So the point is moot.
ok. I've come around... and the point reall is moot.
so.. in that case..another idea...how about a compiler option to output a
list of functions. (I don't really expect many
Clinton wrote:
On Monday, 19 February 2018 at 14:55:01 UTC, Clinton wrote:
Hi all, I need advice from better developers on this concern.
I'm using an AA to reference another array for quicker access:
[...]
Sorry, on second look my explanation isn't very clear. I want to know if:
Nicholas Wilson wrote:
On Thursday, 15 February 2018 at 16:51:05 UTC, Kyle wrote:
Hi. Is there a convenient way to convert a ubyte[4] into a signed int?
I'm having trouble handling the static arrays returned by
std.bitmanip.nativeToLittleEndian. Is there some magic sauce to make the
static
Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread today and I
thought this is an excellent opportunity to revive my blog and finally
write an article showing why I like D so much:
https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d
It's mostly
psychoticRabbit wrote:
Also, if I do this below, how does the compiler choose the correct write
function?
import std.stdio;
import std.file;
void main()
{
write("hello");
writeln("hello again");
}
it's easy: just take a look at `std.file.write()`. first, it require two
psychoticRabbit wrote:
So, strange problem below.
The commented-out line will not compile (if I un-comment it), unless I
either move std.stdio into main, or, move std.file out of main.
Whereas writeln works just fine as is.
-
module test;
import std.stdio;
void main()
welkam wrote:
On Monday, 12 February 2018 at 22:10:49 UTC, Bo wrote:
* Lack of default OFFICIAL libraries like HTTP(s), database access, ...
Why there should be one default OFFICIAL library for anything?
because Business Developers wants it that way. they are... well... Doing
Business,
Bo wrote:
This is part of the issues that D faces. Especially that last sentence...
"bring a significant benefit".
tbh, the only *real* problem with D that i see is people who thinks that D
(and D devs) should do everything to please "business developers". 'cause,
you know, there is no
lobo wrote:
sure, i meant that you have to modify the second parameter accordingly. ;-)
anyway, it's good that you fixed it.
Norm wrote:
Hi,
I'm new to D so can someone explain to me what is happening here?
void func(const char* s, char** e) {
import core.stdc.stdlib;
auto result = strtod(s, e);
}
Error: function core.stdc.stdlib.strtod (scope inout(char)* nptr, scope
inout(char)** endptr) is not
Bastiaan Veelo wrote:
On Wednesday, 7 February 2018 at 11:37:19 UTC, Michael wrote:
Does it work with slightly varied examples like where a = -1, and is
incremented etc.?
I played with it here https://run.dlang.io/is/15sr6c and every variation
I tried worked (correctly). So the example
Mike Franklin wrote:
And what does "NB" mean?
"nota bene". used as "pay attention to the following".
Steven Schveighoffer wrote:
I shudder at the thought of compiled code being affected by documentation.
I don't like it, sorry.
it's not really different from `version(DDoc)`, or string mixins, or UDAs.
i can put documentation in UDA, and process code differently when UDA
changes. yes, UDA
Russel Winder wrote:
I think we are now in a world where Rust is the zero cost abstraction
language to replace C and C++, except for those who are determined to
stay with C++ and evolve it.
sorry, but it is not zero cost. we have alot of C and C++ code. converting
it to Rust is not zero cost
bpr wrote:
It seems that there's an effort from the top to bring more higher level
features into --betterC. I agree with you that more should be there, that
it should really be betterC++ and strive for feature parity with modern
C++.
we already have better c++: it is titled "D".
crimaniak wrote:
Both operands are the same type, so as I understand casting to longest
type is not needed at all, and longest type here is ushort in any case.
What am I doing wrong?
it is hidden in specs: all types shorter than int are promoted to int
before doing any math.
Andrej Mitrovic wrote:
ah, 'cmon, we can hash the whole source file! let's move build system's
work to linker! ;-)
sorry, but this is really overkill. tracking changed files and rebuilding
'em on demand is something your build system should do.
Steven Schveighoffer wrote:
I insist that auto is a storage qualifier
what is the rationale to have `auto` as storage qualifier? except of
keeping it in line with the ancient C feature (and most C programmers don't
even know what `auto` does in C).
i bet that most people are sure that
rikki cattermole wrote:
On 19/12/2017 11:30 AM, ketmar wrote:
rikki cattermole wrote:
On 19/12/2017 9:54 AM, Walter Bright wrote:
"C, Python, Go, and the Generalized Greenspun Law"
http://esr.ibiblio.org/?p=7804
I must agree, GC is a wonderful fallback.
Although I do wish we had better
rikki cattermole wrote:
On 19/12/2017 9:54 AM, Walter Bright wrote:
"C, Python, Go, and the Generalized Greenspun Law"
http://esr.ibiblio.org/?p=7804
I must agree, GC is a wonderful fallback.
Although I do wish we had better scope+RC support.
but Rikki, we have this! i'm using refcounted
cosinus wrote:
So my question is would it be a good idea to have some kind of implicit
declarations of variables that are used as parameters:
```D
int add(decl ref int c, int a, int b);
// ...
// c is unknown here
if(add(c, 123, 456)) {
writeln("error!");
}
// c is implicit declared
great. yet i think that the page should note that people are listed in
alphabetical order, not in any "importance" order.
kerdemdemir wrote:
On Saturday, 16 December 2017 at 20:56:26 UTC, ketmar wrote:
kerdemdemir wrote:
As far as I know scope(failure) should be collecting all failure cases.
nope. `failure` scope won't stop exception propagation, it is just
called before exception leaves your function, to
kerdemdemir wrote:
As far as I know scope(failure) should be collecting all failure cases.
nope. `failure` scope won't stop exception propagation, it is just called
before exception leaves your function, to give you a last chance to do some
immediate cleanup.
Taylor Hillegeist wrote:
On Monday, 11 December 2017 at 19:34:56 UTC, ketmar wrote:
major update: entity logic is completely driven by external
...
you're welcome to study MES compiler implementation if you like. it is
contained in one file (mesengine.d), and is not that hard to follow.
I
1 - 100 of 3410 matches
Mail list logo
