Just tested on Windows and looks very good and useful, thanks!
I have one question, is there by chance a way to extend Tk in D
in order to create a grid like widget (excel, winforms grid view
look alike)?
If yes any hints would be much appreciated. IMHO, two widgets are
missing in
http://www.reddit.com/r/programming/comments/251s5i/tkd_cross_platform_gui_toolkit_for_d_based_on/
https://twitter.com/D_Programming/status/464434846849179648
https://www.facebook.com/dlang.org/posts/843295265684156
https://hn.algolia.com/#!/story/forever/0/Tkd
Andrei
On 5/8/14, Andrei Alexandrescu via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
http://www.reddit.com/r/programming/comments/251s5i/tkd_cross_platform_gui_toolkit_for_d_based_on/
https://twitter.com/D_Programming/status/464434846849179648
On Thursday, 8 May 2014 at 16:05:50 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/251s5i/tkd_cross_platform_gui_toolkit_for_d_based_on/
https://twitter.com/D_Programming/status/464434846849179648
https://www.facebook.com/dlang.org/posts/843295265684156
On Thursday, 8 May 2014 at 06:49:40 UTC, Stef Kariotidis wrote:
I have one question, is there by chance a way to extend Tk in D
in order to create a grid like widget (excel, winforms grid
view look alike)?
If yes any hints would be much appreciated. IMHO, two widgets
are missing in
On 5/8/2014 1:46 PM, Gary Willoughby wrote:
If you're building the next Steam or Spotify use Qt/Gtk.
Or better yet, don't. Steam's UI is terrible. Clicking search
suggestions often does nothing, the search result paging is goofy as
hell and very impractical, the whole thing's absurdly
On Thursday, 8 May 2014 at 17:10:10 UTC, FrankLike wrote:
Hello,
TKD is very nice, and it's easy to use,but how to build it to
small? Such as the size is below to 1M, not must have the lib
,and Memory usage is below to 3M.
Can you please stop asking that in every thread. Tkd depends on
Tcl/Tk
On Thu, May 08, 2014 at 15:41:57 -0400, Nick Sabalausky via
Digitalmars-d-announce wrote:
Or better yet, don't. Steam's UI is terrible. Clicking search
suggestions often does nothing, the search result paging is goofy as
hell and very impractical, the whole thing's absurdly sluggish, in
On 5/8/2014 4:35 PM, Ben Boeckel via Digitalmars-d-announce wrote:
On Thu, May 08, 2014 at 15:41:57 -0400, Nick Sabalausky via
Digitalmars-d-announce wrote:
Or better yet, don't. Steam's UI is terrible. Clicking search
suggestions often does nothing, the search result paging is goofy as
hell
Am 08.05.2014 21:41, schrieb Nick Sabalausky:
(...)my trackpad's scrolling gestures
don't even fucking work on it (they work fine on nearly anything else).
To be fair, some time ago I've had the joy to try and properly support
scrolling gestures properly for my UI framework and I wound up
On 5/8/2014 4:51 PM, Sönke Ludwig wrote:
Am 08.05.2014 21:41, schrieb Nick Sabalausky:
(...)my trackpad's scrolling gestures
don't even fucking work on it (they work fine on nearly anything else).
To be fair, some time ago I've had the joy to try and properly support
scrolling gestures
On 08/05/14 00:22, Etienne wrote:
Yes :
Label label3 =
new
Label(shell, SWT.NONE);
label3.setSize(100,20);
label3.setLocation(30,150);
label3.setBackground(
new
Color(display,200,111,50));
label3.setText(
Speak no evil
);
Thanks, I'll have a look. Could you please report an issue here as
On 08/05/14 05:54, iridium wrote:
Which as I collected a druntime. But in the link step, the following:
http://itmages.ru/image/view/1655530/a5ca9557
You need to link with the C library as well. When compiling with DMD, it
uses GCC to link.
--
/Jacob Carlborg
On 08/05/14 06:54, Etienne Cimon wrote:
I wrote a zlib.mak file for statically compiling the new zlib 1.2.8 on
dmc, using make -fzlib.mak
Isn't zlib already included in Phobos. It contains the sources at least.
--
/Jacob Carlborg
On Wednesday, 7 May 2014 at 20:09:07 UTC, Xavier Bigand wrote:
Le 07/05/2014 05:58, Manu via Digitalmars-d a écrit :
On 7 May 2014 08:07, Xavier Bigand via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Le 06/05/2014 13:39, Paulo Pinto a écrit :
Android works well, I love my nexus, it
Andrei Alexandrescu:
making user-defined types as powerful as built-in types is a
Good Thing(tm).
An example of something useful that I think is not currently easy
to do with user-defined types (but I think this could be done by
future built-in tuples):
Tuple!(ref int, bool) foo(ref int
On Thursday, 8 May 2014 at 06:07:23 UTC, Jacob Carlborg wrote:
On 08/05/14 05:54, iridium wrote:
Which as I collected a druntime. But in the link step, the
following:
http://itmages.ru/image/view/1655530/a5ca9557
You need to link with the C library as well. When compiling
with DMD, it uses
On Wed, 07 May 2014 20:58:21 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
So there's this recent discussion about making T[] be refcounted if
and only if T has a destructor.
That's an interesting idea. More generally, there's the notion that
making
On Thu, 08 May 2014 06:48:57 +
bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
Currently only the slices decay in mutables, while an immutable
int doesn't become mutable:
That's because what's happening is that the slice operator for arrays is
defined to return a tail-const
Just a general note: This is not only interesting for range/slice types,
but for any user defined reference type (e.g. RefCounted!T or Isolated!T).
On 08/05/14 08:53, iridium wrote:
That's what happens when linking:
http://itmages.ru/image/view/1655772/669acb30
You need to link with both Phobos and the C standard library. Run dmd
-v main.d and look at the linking step at the end.
--
/Jacob Carlborg
On Thursday, 8 May 2014 at 07:55:04 UTC, Jacob Carlborg wrote:
On 08/05/14 08:53, iridium wrote:
That's what happens when linking:
http://itmages.ru/image/view/1655772/669acb30
You need to link with both Phobos and the C standard library.
Run dmd -v main.d and look at the linking step at
On Wednesday, 7 May 2014 at 18:26:08 UTC, Maxime
Chevalier-Boisvert wrote:
I have a very specific use case (JIT compiler) in which I have
a pre-allocated array of wchar string data stored somewhere in
memory. I'd like to be able to create a temporary D wstring
object to pass this as a regular
On Thursday, 8 May 2014 at 01:52:05 UTC, Domain wrote:
On Wednesday, 7 May 2014 at 18:24:23 UTC, Kapps wrote:
On Wednesday, 7 May 2014 at 16:51:10 UTC, amehat wrote:
Hello everyone,
I'm working on porting a java library in D, and I stuck on a
class because it works with the reflection.
On Wednesday, 7 May 2014 at 18:34:10 UTC, Meta wrote:
On Wednesday, 7 May 2014 at 18:29:23 UTC, Brad Anderson wrote:
Unless I'm misunderstanding it should be as simple as:
wchar[100] stackws; // alloca() if you need it to be
dynamically sized.
A slice of this static array behaves just like
John Colvin:
Sure, you have to keep track of the memory to make sure it
doesn't survive past the current scope (or at least isn't used
past that point, depending on how security critical your
application is), but that's often trivial to do and saving the
extra allocation can make a big
On 05/08/2014 05:58 AM, Andrei Alexandrescu wrote:
...
import std.stdio;
void fun(T)(T x)
{
writeln(typeof(x).stringof);
}
void main()
{
immutable(int[]) a = [ 1, 2 ];
writeln(typeof(a).stringof);
fun(a);
}
This program outputs:
immutable(int[])
immutable(int)[]
which means
On Thursday, 8 May 2014 at 08:18:16 UTC, iridium wrote:
On Thursday, 8 May 2014 at 07:55:04 UTC, Jacob Carlborg wrote:
On 08/05/14 08:53, iridium wrote:
That's what happens when linking:
http://itmages.ru/image/view/1655772/669acb30
You need to link with both Phobos and the C standard
On 2014-05-08 03:58:21 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
So there's this recent discussion about making T[] be refcounted if and
only if T has a destructor.
That's an interesting idea. More generally, there's the notion that
making user-defined types as powerful
On 05/08/2014 08:55 AM, Jonathan M Davis via Digitalmars-d wrote:
As far as I can see, opByValue does the same thing as opSlice, except
that it's used specifically when passing to functions, whereas this code
immutable int [] a = [1, 2, 3];
immutable(int)[] b = a[];
or even
immutable int [] a
On 05/08/2014 12:14 PM, Michel Fortin wrote:
Will this solve the problem that const(MyRange!(const T)) is a different
type from const(MyRange!(T))?
No, but as stated it aggravates this problem.
I doubt it. But they should be the same
type if we want to follow the semantics of the language's
On Thu, 08 May 2014 12:38:44 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 05/08/2014 08:55 AM, Jonathan M Davis via Digitalmars-d wrote:
As far as I can see, opByValue does the same thing as opSlice,
except that it's used specifically when passing to functions,
On 05/08/2014 09:01 AM, Jonathan M Davis via Digitalmars-d wrote:
It really has nothing to do with passing an argument to a function
beyond the fact that that triggers an implicit call to the slice operator.
module check_claim;
import std.stdio;
auto foo(immutable(int)[] a){writeln(Indeed,
On Thursday, 8 May 2014 at 03:58:16 UTC, Andrei Alexandrescu
wrote:
This change would allow library designers to provide good
solutions to making immutable and const ranges work properly -
the way T[] works.
There are of course a bunch of details to think about and
figure out, and this is a
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for
range/slice types, but for any user defined reference type
(e.g. RefCounted!T or Isolated!T).
Not necessarily: As soon as indirections come into play, you are
basically screwed,
Am 08.05.2014 13:05, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for range/slice
types, but for any user defined reference type (e.g. RefCounted!T or
Isolated!T).
Not necessarily: As soon as indirections
On Wednesday, 7 May 2014 at 16:09:28 UTC, Atila Neves wrote:
They can. But those descriptions are not included in failing
test output. What I think Jacob might be getting to as well is
that assertEquals or the more RSpec-like foo.should equal 3
is more readable than the raw asserts.
The
On Tuesday, 6 May 2014 at 20:41:01 UTC, Andrei Alexandrescu wrote:
On 5/6/14, 11:27 AM, Dicebot wrote:
On Tuesday, 6 May 2014 at 18:13:01 UTC, Andrei Alexandrescu
wrote:
On 5/6/14, 10:43 AM, Dicebot wrote:
Disk I/O failure throws Exception which can be easily
consumed somewhere
inside tested
On Wednesday, 7 May 2014 at 14:34:41 UTC, Bruno Medeiros wrote:
On 06/05/2014 18:58, Dicebot wrote:
I see no good in trying to unite those very different beasts
and my
experience with existing test libraries has been very
unpleasant in that
regard.
What test libraries/frameworks have you
DMD has a VS project, is there an objection to one for phobos too?
On 2014-05-08 02:09, Jacob Carlborg wrote:
On 08/05/14 00:22, Etienne wrote:
Yes :
Label label3 =
new
Label(shell, SWT.NONE);
label3.setSize(100,20);
label3.setLocation(30,150);
label3.setBackground(
new
Color(display,200,111,50));
label3.setText(
Speak no evil
);
Thanks, I'll have a
On 2014-05-08 02:08, Jacob Carlborg wrote:
On 08/05/14 06:54, Etienne Cimon wrote:
I wrote a zlib.mak file for statically compiling the new zlib 1.2.8 on
dmc, using make -fzlib.mak
Isn't zlib already included in Phobos. It contains the sources at least.
Yes, I see version 1.2.5 here:
On Thu, 2014-05-08 at 13:03 +, Dicebot via Digitalmars-d wrote:
[…]
I have C/C++ origins so it was mostly stuff like cppUnit, xUnit
and Boost one as far as I can remember.
The current C++ test framework front runner is probably Phil Nash's
Catch https://github.com/philsquared/Catch
--
It would mean that a VisualD project for druntime, as well as a
VisualC++ project for zlib, would be required. The issue I see is that
while I know that Mono-D can open VisualD project files, as well as
dub projects, and mono-d project files, I don't know if it can open
VisualC++ project files,
On Thursday, 8 May 2014 at 12:48:17 UTC, Sönke Ludwig wrote:
Am 08.05.2014 13:05, schrieb monarch_dodra:
Not necessarily: As soon as indirections come into play, you
are
basically screwed, since const is turtles all the way down.
So for example, the conversion from const RefCounted!T to
Andrei Alexandrescu:
Added SbrkRegion, SimpleBlocklist, and Blocklist.
An interesting paper, Reconsidering Custom Memory Allocation -
Allen B. Downey:
http://www.allendowney.com/ss08/handouts/berger02reconsidering.pdf
Bye,
bearophile
On 5/8/14, 7:02 AM, bearophile wrote:
Andrei Alexandrescu:
Added SbrkRegion, SimpleBlocklist, and Blocklist.
An interesting paper, Reconsidering Custom Memory Allocation - Allen B.
Downey:
http://www.allendowney.com/ss08/handouts/berger02reconsidering.pdf
Bye,
bearophile
Yeah, it's a
On 05/08/2014 01:05 PM, monarch_dodra wrote:
...
In fact, I'm wondering if this might not be a more interesting direction
to explore.
http://forum.dlang.org/thread/ljrm0d$28vf$1...@digitalmars.com?page=3#post-ljrt6t:242fpc:241:40digitalmars.com
What's the reasoning for the current behavior of add/remove range?
This is actually something that I had almost forgotten about in my GC
design, so I thank you for reminding me of it :D After a preliminary
think-through of the design, I would end up going with the first
possibility, so that
Andrei Alexandrescu:
(related: http://erdani.com/publications/cuj-2005-12.pdf :o))
I have never read this paper. I will read it asap, thank you.
After the work on D allocators, and a testing/data collecting
phase, perhaps you will have material to write another paper.
Bye,
bearophile
On Thursday, 8 May 2014 at 13:32:28 UTC, Manu via Digitalmars-d
wrote:
DMD has a VS project, is there an objection to one for phobos
too?
If you are willing to maintain it.
On 8 May 2014 23:58, Orvid King via Digitalmars-d
digitalmars-d@puremagic.com wrote:
It would mean that a VisualD project for druntime, as well as a
VisualC++ project for zlib, would be required. The issue I see is that
while I know that Mono-D can open VisualD project files, as well as
dub
On Thu, 08 May 2014 14:48:18 +0200
Sönke Ludwig via Digitalmars-d digitalmars-d@puremagic.com wrote:
Am 08.05.2014 13:05, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for range/slice
types, but for any
On Wed, 07 May 2014 00:11:45 -0400, Mike n...@none.com wrote:
On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote:
Hi all,
After last year's incident with my tires getting slashed, I'm really
hoping I can do without a car during this year's DConf. How feasible is
this?
I'll be
On Thu, May 08, 2014 at 11:05:19AM +, monarch_dodra via Digitalmars-d wrote:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for range/slice
types, but for any user defined reference type (e.g. RefCounted!T or
Isolated!T).
Am 08.05.2014 15:57, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 12:48:17 UTC, Sönke Ludwig wrote:
Am 08.05.2014 13:05, schrieb monarch_dodra:
Not necessarily: As soon as indirections come into play, you are
basically screwed, since const is turtles all the way down.
So for example, the
On 9 May 2014 00:27, Manu turkey...@gmail.com wrote:
On 8 May 2014 23:58, Orvid King via Digitalmars-d
digitalmars-d@puremagic.com wrote:
It would mean that a VisualD project for druntime, as well as a
VisualC++ project for zlib, would be required. The issue I see is that
while I know that
On 5/8/14, 7:24 AM, bearophile wrote:
Andrei Alexandrescu:
(related: http://erdani.com/publications/cuj-2005-12.pdf :o))
I have never read this paper. I will read it asap, thank you.
After the work on D allocators, and a testing/data collecting phase,
perhaps you will have material to write
Am 08.05.2014 16:22, schrieb Jonathan M Davis via Digitalmars-d:
On Thu, 08 May 2014 14:48:18 +0200
Sönke Ludwig via Digitalmars-d digitalmars-d@puremagic.com wrote:
Am 08.05.2014 13:05, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note:
On Thursday, 8 May 2014 at 15:23:35 UTC, Manu via Digitalmars-d
wrote:
Trying to understand this bit... why is $(ZLIB) $(DRUNTIMELIB)
provided to the compiler? It's building the phobos lib right,
not
linking anything?
druntime and zlib are statically linked into Phobos
On 9 May 2014 01:38, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 8 May 2014 at 15:23:35 UTC, Manu via Digitalmars-d wrote:
Trying to understand this bit... why is $(ZLIB) $(DRUNTIMELIB)
provided to the compiler? It's building the phobos lib right, not
linking
On Thursday, 8 May 2014 at 15:52:37 UTC, Manu via Digitalmars-d
wrote:
On 9 May 2014 01:38, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 8 May 2014 at 15:23:35 UTC, Manu via
Digitalmars-d wrote:
Trying to understand this bit... why is $(ZLIB) $(DRUNTIMELIB)
On Thursday, 8 May 2014 at 15:39:24 UTC, Sönke Ludwig wrote:
Unless I'm completely mistaken, it's safe to cast away const
when it is known that the original reference was constructed as
mutable.
Depends. If the original type referencing the (originally
mutable) allocated data happens to be
On 5/7/14, 12:53 PM, Andrei Alexandrescu wrote:
On 5/7/14, 12:29 PM, Gary Willoughby wrote:
On Sunday, 4 May 2014 at 17:51:50 UTC, Andrei Alexandrescu wrote:
On 5/4/14, 9:19 AM, Gary Willoughby wrote:
On Sunday, 4 May 2014 at 14:09:38 UTC, w0rp wrote:
Best of luck to you guys. I encourage as
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you can cast
away all the const you want, but at that point, it kind of makes the
whole const thing moot.
This is not guaranteed to work. I guess the only related thing that is
safe to do
Well, Android/x86 for now. I've been plugging away at getting D
running on Android/x86 and got all of the druntime modules' unit
tests and 37 of 50 phobos modules' unit tests to pass. I had to
hack dmd into producing something like packed TLS for ELF, my
patch is online here:
On Thursday, 8 May 2014 at 16:30:13 UTC, Sönke Ludwig wrote:
For what practical reason would that be the case? I know that
the spec states undefined behavior, but AFAICS, there is
neither an existing, nor a theoretical reason, why this should
fail:
Compiler optimizations based on
Am 08.05.2014 18:10, schrieb Timon Gehr:
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you can cast
away all the const you want, but at that point, it kind of makes the
whole const thing moot.
This is not guaranteed to work. I guess
On Thursday, 8 May 2014 at 16:16:22 UTC, Joakim wrote:
Well, Android/x86 for now. I've been plugging away at getting
D running on Android/x86 and got all of the druntime modules'
unit tests and 37 of 50 phobos modules' unit tests to pass. I
had to hack dmd into producing something like packed
Am 08.05.2014 18:33, schrieb David Nadlinger:
On Thursday, 8 May 2014 at 16:30:13 UTC, Sönke Ludwig wrote:
For what practical reason would that be the case? I know that the spec
states undefined behavior, but AFAICS, there is neither an existing,
nor a theoretical reason, why this should fail:
Am 08.05.2014 18:02, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 15:39:24 UTC, Sönke Ludwig wrote:
Unless I'm completely mistaken, it's safe to cast away const when it
is known that the original reference was constructed as mutable.
Depends. If the original type referencing the
On 2/27/14, 4:41 AM, Szymon Gatner wrote:
C#'s IObservable/IObserver made me think how would a dual [1][2] of
a range concept look in D. Since D has no equivalent IEnumerable (as
it is no needed thanks to templates) it is only about IEnumerator /
IObserver part which relates to a D range.
http://www.reddit.com/r/programming/comments/251s5i/tkd_cross_platform_gui_toolkit_for_d_based_on/
https://twitter.com/D_Programming/status/464434846849179648
https://www.facebook.com/dlang.org/posts/843295265684156
https://hn.algolia.com/#!/story/forever/0/Tkd
Andrei
Hello,
TKD is very
http://www.reddit.com/r/programming/comments/251s5i/tkd_cross_platform_gui_toolkit_for_d_based_on/
https://twitter.com/D_Programming/status/464434846849179648
https://www.facebook.com/dlang.org/posts/843295265684156
https://hn.algolia.com/#!/story/forever/0/Tkd
Andrei
Hello,
TKD is very
On 5/4/2014 4:08 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
I should also be thanking you -- this reminded me that I needed to make
some key changes to my std.random2 proposal, including this stricter
isUniformRNG template:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a
nice initiative by Walter to allow Phobos users to avoid or control
memory allocation.
First instance of the pull request copied the inputs into an output range.
The second instance (right
On Thursday, 8 May 2014 at 14:20:58 UTC, Orvid King via
Digitalmars-d wrote:
What's the reasoning for the current behavior of add/remove
range?
I think the behaviour only stems from the simple implementation
rather than reason.
After sleeping on the question, I realise there's no way around
Awesome. I appreciate this work.
On Thu, May 08, 2014 at 10:46:12AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a
nice initiative by Walter to allow Phobos users to avoid or control
memory allocation.
First
Hello D community,
What do you think of a new __traits(getImports, Scope), that
returns a tuple of strings, which are imports made in a scope? If
scope is a module, it will produce a tuple like (std.conv,
std.traits).
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a nice
initiative by Walter to allow Phobos users to avoid or control memory
allocation.
The setExtension() function is itself not very
On Wednesday, 7 May 2014 at 15:54:42 UTC, Paulo Pinto wrote:
So the videos of the Gophercon 2014 are being made available.
Rob Pike did the keynote. At the expected question about
generics,
his answer was There are no plans for generics. I said we're
going to leave the language; we're done..
Yuriy:
What do you think of a new __traits(getImports, Scope), that
returns a tuple of strings, which are imports made in a scope?
If scope is a module, it will produce a tuple like (std.conv,
std.traits).
Please explain one or more use cases.
Bye,
bearophile
On Thu, May 08, 2014 at 11:27:54AM -0700, Walter Bright via Digitalmars-d wrote:
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a nice
initiative by Walter to allow Phobos users to avoid or
On 2014-05-08 15:50, Etienne Cimon wrote:
I saw the dll in the dmd2 bin folder so I assumed it was necessary. Is it?
Actually, I don't know. I just know the zlib source code is included in
Phobos, in etc/c/zlib.
--
/Jacob Carlborg
You can actually get imports on module level now with
__traits(allMembers). They'll be seen as members whose .stringof
startsWith(module ).
But it won't work on a local scope.
On 5/8/2014 1:46 PM, Andrei Alexandrescu wrote:
However output range means the string operation will be done eagerly,
whereas lazy has advantages (nice piping, saving on work etc).
Isn't eagerness what we have array() for?
Also, while naming is often just bikeshedding, in this case I think
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
However output range means the string operation will be done eagerly, whereas
lazy has advantages (nice piping, saving on work etc).
The lazy vs eager issue seems at first blush to be an esoteric, potayto-potahto
bikeshed.
But I think it's
On 5/8/2014 11:19 AM, H. S. Teoh via Digitalmars-d wrote:
In case 1, the user has to manually create various intermediate buffers
to store intermediate results. I used a trivial example here, but in
application code, the processing you need is usually far more complex.
This means creating lots
On 2014-05-08 14:56, Dicebot wrote:
You don't need artificial pseudo syntax for that.
assert!(==) + named tests is good enough to get the context and for
detailed investigation you need file and line number anyway. Stuff like
RSpec is extreme opposite of KISS.
RSpec uses a syntax that makes
On 5/8/2014 2:19 PM, H. S. Teoh via Digitalmars-d wrote:
This way, you maximize the usability of the function -- it can
participate in UFCS chains, compose with other std.algorithm functions,
etc..
I think that actually raises an issue worth considering. I posit that
the results of an
Adam, that doesn't seem to work for me:
import std.typetuple;
import std.string;
import std.stdio;
template isImport(string i)
{
static if (__traits(compiles, mixin(i).stringof)
mixin(i).stringof.startsWith(module ))
enum isImport = true;
else
enum isImport = false;
}
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
And note also there is such as thing as a stackless fiber, so I'm not
certain a full-fledged context-switching fiber would necessarily
On Thursday, 8 May 2014 at 17:46:06 UTC, Andrei Alexandrescu
wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149,
which is a nice initiative by Walter to allow Phobos users to
avoid or control memory allocation.
First instance of the pull request
On Thursday, 8 May 2014 at 18:29:45 UTC, Jesse Phillips wrote:
This statement doesn't sound like the no generics is the
important part. It seems more like they have no plans to make
Go 2.0, at least not with it bringing big breaking changes as
people keep pointing out will happen.
But that
I wrote a D application, using zlib from phobos, it didn't
require dll, IIRC.
Reactive programming is related to dataflow, so you will run into
problems when you get beyond toy-size programs. Though, with
compiler support…
http://cs.brown.edu/~sk/Publications/Papers/Published/bck-lowering-opt-trans-frp/paper.pdf
On Wednesday, 7 May 2014 at 20:02:20 UTC, Russel Winder via
Digitalmars-d wrote:
On Wed, 2014-05-07 at 12:53 -0700, Andrei Alexandrescu via
Digitalmars-d
wrote:
[…]
9 AM PST. Will do tomorrow. -- Andrei
So what is that in ISO 8601 time. Get with the programme…
;-)
Pacific Standard Time,
On 5/8/2014 12:22 PM, Nick Sabalausky wrote:
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
The data is still supplied to it.
On Thursday, 8 May 2014 at 18:21:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
I've thought about input ranges vs. output ranges for a bit. I
think it
doesn't make sense for functions that process data to take an
output
range: output ranges are data sinks, and should only be used
for the
1 - 100 of 216 matches
Mail list logo