The whole webpage https://forum.dlang.org/ has only 300KB in
size. It not only supports mobile devices, but also loads much
faster than general modern web pages.
How can they achieve such result?
On Tuesday, 24 May 2016 at 16:22:56 UTC, Timon Gehr wrote:
It's _exponential_ growth. We don't even want to spend the time
and memory required to generate the strings.
The reason we have this discussion is that the worst case isn't
rare enough to make this argument. Why compress in the first
On Sunday, 22 May 2016 at 21:40:07 UTC, Andrei Alexandrescu wrote:
On 05/21/2016 06:27 PM, Anon wrote:
On Saturday, 21 May 2016 at 20:50:56 UTC, Walter Bright wrote:
On 5/21/2016 1:49 PM, Walter Bright wrote:
We already have a compressor in the compiler source for
compressing
names:
https
On Saturday, 21 May 2016 at 20:50:56 UTC, Walter Bright wrote:
On 5/21/2016 1:49 PM, Walter Bright wrote:
We already have a compressor in the compiler source for
compressing names:
https://github.com/dlang/dmd/blob/master/src/backend/compress.c
A faster one would certainly be nice. Anyone
On Thursday, 12 May 2016 at 08:41:25 UTC, John Burton wrote:
I've been unable to find a clear definitive answer to this so
please point me to one if it already exists in the manual or
the forums.
Is it safe to cast pointer types?
double data;
long p = *cast(long*)&data;
(Excuse any s
On Friday, 6 May 2016 at 20:32:59 UTC, Assi Zanafi wrote:
Quantum CPU before x86_128 ? what do you think ?
I really think that x86_64 is the last "classic architecture".
Intel will never make x86 with 128 bits addresses. Qbytes will
raise before.
I don't know which will come first, but QPUs w
On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:
It's touchy, because I've come across people who actually do
genuinely believe the field has things in place deliberately to
exclude women/ethnicities...even though...those VERY SAME
people have never once been able to provide a S
On Thursday, 31 March 2016 at 20:40:03 UTC, Adam D. Ruppe wrote:
meh, if it is allowed, it is going to happen. Why make it worse
when there's so little cost in making it better?
Define "little cost". Whatever compression algorithm chosen will
need support added to any/all tools that want to de
On Thursday, 31 March 2016 at 17:52:43 UTC, Adam D. Ruppe wrote:
Yeah, but my thought is the typical use case isn't actually the
problem - it is OK as it is. Longer strings are where it gets
concerning to me.
Doubling the size of UTF-8 (the effect of the current base16
encoding) bothers me re
On Thursday, 31 March 2016 at 16:46:42 UTC, Adam D. Ruppe wrote:
On Thursday, 31 March 2016 at 16:38:59 UTC, Anon wrote:
I've been spending my D time thinking about potential changes
to how template string value parameters are encoded.
How does it compare to simply gzipping the strin
On Thursday, 31 March 2016 at 11:15:18 UTC, Johan Engelen wrote:
Hi Anon,
I've started implementing your idea. But perhaps you already
have a beginning of an implementation? If so, please contact me
:)
https://github.com/JohanEngelen
Thanks,
Johan
No, I haven't started i
On Wednesday, 30 March 2016 at 15:26:21 UTC, Seb wrote:
On Wednesday, 30 March 2016 at 12:57:56 UTC, Mathias Lang wrote:
My question is whether this is just an open issue (I couldn't
find it) or a design decision?
It's a design decision. You want to be able to fix the exact
type of your funct
On Saturday, 26 March 2016 at 05:22:56 UTC, Andrei Alexandrescu
wrote:
On 03/25/2016 11:40 AM, Steven Schveighoffer wrote:
On 3/25/16 11:07 AM, Andrei Alexandrescu wrote:
On 3/25/16 10:07 AM, Steven Schveighoffer wrote:
We should actually be moving *away from* voldemort types:
https://forum.
On Friday, 25 March 2016 at 18:20:12 UTC, Steven Schveighoffer
wrote:
On 3/25/16 12:18 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Mar 25, 2016 at 11:40:11AM -0400, Steven Schveighoffer
via Digitalmars-d wrote:
On 3/25/16 11:07 AM, Andrei Alexandrescu wrote:
On 3/25/16 10:07 AM, Steven Sch
On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright
wrote:
Show a way to read or write outside allocated memory with this,
or to cause a segmentation fault, and that will require a
change in @safe. You're looking for something else, data safety
rather than memory safety. You want to
On Friday, 22 January 2016 at 16:37:31 UTC, Jacob Carlborg wrote:
On 2016-01-21 05:21, Anon wrote:
Seeing the recent extern(C++) threads, and much concern
therein, I'd
like to propose DIP87: http://wiki.dlang.org/DIP87
Destroy to your heart's content.
* How do you plan to dif
On Thursday, 21 January 2016 at 04:42:00 UTC, Rikki Cattermole
wrote:
On 21/01/16 5:21 PM, Anon wrote:
Seeing the recent extern(C++) threads, and much concern
therein, I'd
like to propose DIP87: http://wiki.dlang.org/DIP87
Destroy to your heart's content.
It was great until I s
On Thursday, 21 January 2016 at 01:37:12 UTC, Walter Bright wrote:
On 1/20/2016 4:51 PM, Anon wrote:
What would you all say to the following proposal (and should I
make a DIP?)
DIPs are always welcome.
Done.
http://forum.dlang.org/post/ldtluvnhuznvbebcb...@forum.dlang.org
Seeing the recent extern(C++) threads, and much concern therein,
I'd like to propose DIP87: http://wiki.dlang.org/DIP87
Destroy to your heart's content.
What would you all say to the following proposal (and should I
make a DIP?)
1. deprecate pragma(mangle)
2. deprecate extern(C++, ns)
3. deprecate @selector()
4. Introduce a better, more general extern() as follows:
extern ( [, ] )
Which would *only* influence mangling and calling convention
On Monday, 18 January 2016 at 19:32:19 UTC, bitwise wrote:
struct S;
void func(ref S s);
func(S()); // FINE
void func(ref S s) @safe;
func(S()); // ERROR
Isn't that backwards? I mean, @safe functions can't escape their
parameters, so whether or not it is a temporary shouldn't matter
to
On Thursday, 17 December 2015 at 20:04:44 UTC, jmh530 wrote:
My feedback: add the ability to edit posts in the forum
You can't edit email.
On Friday, 23 October 2015 at 21:22:38 UTC, Vladimir Panteleev
wrote:
That doesn't sound right. In fact, this puts into question why
dchar.max is at the value it is now. It might be the current
maximum at the current version of Unicode, but this seems like
a completely pointless restriction tha
On Friday, 25 September 2015 at 15:17:02 UTC, Cauterite wrote:
The prospect of writing kernel-mode drivers in D doesn't seem
to get mentioned very often. I know there's been some attempts
in the past at running D in the kernel, such as XOmB, but no
mention of doing so on Windows.
I gave it a sh
On Saturday, 26 September 2015 at 01:37:57 UTC, Manu wrote:
On 25 September 2015 at 22:17, Kagamin via Digitalmars-d
wrote:
[...]
This is because I am constantly introducing new users to D, and
even
more important when those users are colleagues in my workplace.
If I talk about how cool D i
On Tuesday, 16 June 2015 at 00:47:59 UTC, Ramon wrote:
Hi folks
Just want to share some insights about what you can achieve
with the D programming language and the Sciter library, which I
use for making the GUI interface.
I've written the OctoDeskdex app, which is basically the
Github's Oct
On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote:
On 2015-03-11 17:27, Anon wrote:
Ignoring that for a moment, where does it stop? Do we include
an
editor? [sarcasm] Why not? Every D developer needs to edit
their
code! Let's go ahead and call Eclipse+DDT the "s
On Wednesday, 11 March 2015 at 07:19:57 UTC, Vladimir Panteleev
wrote:
What is indubitably, actually, very important, and something
I'm surprised you haven't pushed for since long ago, is making
it EASY to get more things. Dub absolutely must be a part of D,
and not today but one or more years
On Wednesday, 11 March 2015 at 16:35:22 UTC, Andrei Alexandrescu
wrote:
On 3/11/15 9:27 AM, Anon wrote:
Not to mention, putting extra tools like dustmite and dub in
dmd
will only ever benefit dmd users, not those of us who use ldc
or
gdc.
That's entirely reasonable. Each distributio
On Wednesday, 31 December 2014 at 19:11:27 UTC, Walter Bright
wrote:
On 12/31/2014 7:20 AM, Vladimir Panteleev wrote:
On Monday, 29 December 2014 at 22:39:02 UTC, Walter Bright
wrote:
* reddit
* github
These both use Markdown. The syntax is the same, except for
minor things, such
as the han
https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages
On Friday, 23 May 2014 at 06:57:06 UTC, Ali Çehreli wrote:
There is word out there that Kenji Hara and bearophile are the
same person. (I think it is the same AI running on a powerful
server farm. :p)
Ali
That explains why he couldn't come to DConf.
I meant to ask this question during Andrei's talk at DConf, but
forgot. Dmitry Saubalausky's talk about regex made me remember,
since regex is one of the major stumbling areas when using CTFE
unless you're careful.
I heard once that you were strongly against using manifest over
enum for manifest
On Sunday, 11 August 2013 at 21:21:45 UTC, bearophile wrote:
Walter Bright:
On the subject of friction, I believe we make a mistake by
making a dependency on libcurl, a library over which we don't
have control. Some issues:
http://d.puremagic.com/issues/show_bug.cgi?id=10710
http://d.purema
Works for me.
I'm glad to see you are still maintaining this - appreciate your
work.
Andrei Alexandrescu Wrote:
> On 10/14/2010 12:15 PM, anon wrote:
> > I can't understand why we need binary vs. text modes. Seems to me a
> > silly design decision from the old days when we used 7-bit terminals
> > or something. This always complicates the APIs for no
Andrei Alexandrescu Wrote:
> Starting a new thread from Denis' question:
>
> > Can we outline basic Stream interface now so that we could move on?
>
> Here's the input transport layer. Transport has no concern for
> formatting - it just moves stuff around.
>
> interface TransportBase
> {
>
37 matches
Mail list logo