On 17 Oct 2013 00:40, bearophile bearophileh...@lycos.com wrote:
Walter Bright:
I'll go have myself flogged, then.
But please be gentle and use something soft, like a fake snow leopard
tail:
Surely having to deal with c++ whenever Walter works on dmd is punishment
enough :D.
On Saturday, 12 October 2013 at 12:08:03 UTC, Todor wrote:
On Friday, 11 October 2013 at 05:11:49 UTC, Walter Bright wrote:
On 10/10/2013 10:05 PM, Nick Sabalausky wrote:
Awesome! Great bragging rights for D :)
It's the first battle signaling the end of Middle Earth, and
the rise of the Age
On 2013-10-16 23:16, Jonathan M Davis wrote:
Yes, but after Andej did the great changelog for 2.063, Walter publicly
admitted that he had been wrong about the changelog. Andrej showed Walter that
it _is_ worth doing something more than just a list of bugzilla issues. So, I
would assume that
On Wed, Oct 16, 2013 at 2:21 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/16/13 5:38 AM, Bruno Medeiros wrote:
On 08/10/2013 14:18, Alexander Bothe wrote:
Are there any plans/tricks/hacks on how to get programs built
with dmd debuggable with gdb? Then we also could
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the fields
description and license present to be published. The
license field has to be set according to the
Am 17.10.2013 11:55, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the fields
description and license present to be published. The
On Thursday, 17 October 2013 at 10:07:40 UTC, Sönke Ludwig wrote:
Am 17.10.2013 11:55, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig
wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the
Am 17.10.2013 12:14, schrieb ilya-stromberg:
Add abbility to add the array with licenses:
license: [BSL-1.0, AFL-3.0, public domain]
I think it's better than
license: BSL-1.0 or AFL-3.0 or public domain
There will still be the need to specify or later, so this will only
make it partially more
But one potential issue just occurred to me. What if a product
is licensed under multiple licenses that must _all_ apply? That
would basically be MPL-2.0 and Apache-1.0 instead of or.
This is something that happens quite frequently when code is
taken from multiple projects or when the license
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote:
But one potential issue just occurred to me. What if a product
is licensed under multiple licenses that must _all_ apply? That
would basically be MPL-2.0 and Apache-1.0 instead of or.
This is something that happens quite
Am 17.10.2013 13:42, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote:
But one potential issue just occurred to me. What if a product is
licensed under multiple licenses that must _all_ apply? That would
basically be MPL-2.0 and Apache-1.0 instead of or.
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both licenses need to be obeyed when using the package. If
those licenses are incompatible, that's a problem of the
package combining them - it's basically unusable
On 10/17/13, Sönke Ludwig slud...@outerproduct.org wrote:
Having a single compact name reduces the
chances for errors
Speaking of which, if I forget to add the license to a package file is
there any way to get this information from the server? I mean like a
page saying that my package was
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package. If those licenses
are incompatible, that's a problem of the
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
Personally I think it would be better if we had a dub publish
command, which would then error back if the server rejects the
package, rather than make this whole process automated based on
searching github (I assume this is how the dub server works
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
On 10/17/13, Sönke Ludwig slud...@outerproduct.org wrote:
Having a single compact name reduces the
chances for errors
Speaking of which, if I forget to add the license to a package file is
there any way to get this information from the server? I
On Thursday, 17 October 2013 at 12:27:02 UTC, Sönke Ludwig wrote:
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig
wrote:
If you have per-file differences, then this in fact means
that both
licenses need to be obeyed when using the
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like something that may considerably increase the
complexity of the command line tool, especially in the long term, and it
also increases the coupling to the public registry, whereas now it just
needs a very small HTTP API that can be
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing packages
to be updated: All packages must now have the fields description and
license present to be published. The license field has to be set
according to the specification [1]. All existing
Am 17.10.2013 15:26, schrieb Jacob Carlborg:
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets, that
don't share any
On Thursday, 17 October 2013 at 13:31:06 UTC, Jacob Carlborg
wrote:
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing
packages
to be updated: All packages must now have the fields
description and
license present to be published. The license
Am 17.10.2013 15:28, schrieb Jacob Carlborg:
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like something that may considerably increase the
complexity of the command line tool, especially in the long term, and it
also increases the coupling to the public registry, whereas now it
The only license JSON that looks valid is the string. Simple bracketing
will suffice for complex licenses.
On 17 Oct 2013 16:05, Sönke Ludwig slud...@outerproduct.org wrote:
Am 17.10.2013 15:28, schrieb Jacob Carlborg:
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like
On Thursday, 17 October 2013 at 13:26:06 UTC, Jacob Carlborg
wrote:
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets,
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two targets.
What's happens then with the main/super package, in regards to licensing?
--
/Jacob
On 2013-10-17 15:53, Sönke Ludwig wrote:
Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public
License).
Cool, thanks.
--
/Jacob Carlborg
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two targets.
What's happens then with the
Am 17.10.2013 17:02, schrieb Sönke Ludwig:
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two
Am 16.10.2013 21:01, schrieb Sönke Ludwig:
The DUB package registry [1] has finally gained support for the text and
category based search of packages. There is also a category for D
standard library candidate modules, as has been suggested recently.
If you already have any registered packages,
On 10/16/13, Brad Roberts bra...@puremagic.com wrote:
That's not a what, that's a who.
- We do not have any vision or major plans ahead for the language.
Currently we're stuck in a bug-driven development environment, where
bugs are arbitrarily picked off of bugzilla and fixed. But there's no
On Wednesday, 16 October 2013 at 17:41:37 UTC, deadalnix wrote:
Hum I have several regression is SDC's test suite. I have to
investigate more to fix the code or submit bug report. It looks
related to AA. What are the changes that affect AA in this new
release ?
It turns out that is is a
On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis wrote:
On Thursday, October 17, 2013 04:49:29 growler wrote:
On Thursday, 17 October 2013 at 02:37:35 UTC, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 10:16:17PM -0400, Jonathan M Davis
[...]
I can't possibly like any language where
Attempt four: http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe
This one has a couple more changes to the dmd2beta.zip it is
downloading from my server.
1. dmd.exe has been replaced with one built from 2.064 branch
HEAD (so I didn't have to use LINKCMD64).
2. lib64 has been added and
On Thursday, 17 October 2013 at 05:27:15 UTC, Brad Anderson wrote:
I'm switching to a simpler approach for this next iteration
which I will post shortly.
http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe
before i tried x64 i was happy to see its finally coming to the
masses, but now, *cough* excuse me, how can we develop x64 apps
if we can't hook debugger? is this something with my
configuration or something on dmd part which denies any
possibility to use debuggers at this moment?
On Thursday, 17 October 2013 at 06:15:43 UTC, evilrat wrote:
before i tried x64 i was happy to see its finally coming to the
masses, but now, *cough* excuse me, how can we develop x64 apps
if we can't hook debugger? is this something with my
configuration or something on dmd part which denies
On Thursday, 17 October 2013 at 06:17:57 UTC, Brad Anderson wrote:
On Thursday, 17 October 2013 at 05:27:15 UTC, Brad Anderson
wrote:
I'm switching to a simpler approach for this next iteration
which I will post shortly.
http://gnuk.net/dmd-2.064-beta-newsc-lib64-4.exe
now it builds and
On 16.10.2013 14:33, Bruno Medeiros wrote:
* How complete is the debugging info for DMD-Win64? Is it fully
implemented, and/or are there any issues or limitations? (Rainer you are
likely the best to answer this one)
The stock compiler does not do the replacement '@' for '.' which
confuses
On Thursday, 17 October 2013 at 06:42:58 UTC, Rainer Schuetze
wrote:
On 16.10.2013 14:33, Bruno Medeiros wrote:
* How complete is the debugging info for DMD-Win64? Is it fully
implemented, and/or are there any issues or limitations?
(Rainer you are
likely the best to answer this one)
The
On 16.10.2013 13:13, Manu wrote:
On 16 October 2013 17:16, Rainer Schuetze r.sagita...@gmx.de
We are trying to talk Walter into doing this but it seems there are
topics that fail to gain traction.
Cool, well if it get's there, I should add that it would be nice to lose
the '64'
On 16.10.2013 18:05, evilrat wrote:
also, does anyone knows why it fails to start debugger on x64 binary
using VisualD?
Are you using VS2012 shell? I was experiencing the same problem, that is
a bug in the shell installer.
The newer Visual D installers fix this problem, the latest is
On 17.10.2013 01:49, Manu wrote:
On 17 October 2013 02:51, dnewbie r...@myopera.com
mailto:r...@myopera.com wrote:
1. 64-bit link.exe:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\link.exe
2. 64-bit C Runtime libraries:
C:\Program Files (x86)\Microsoft
On Thursday, 17 October 2013 at 07:13:20 UTC, Rainer Schuetze
wrote:
On 16.10.2013 18:05, evilrat wrote:
also, does anyone knows why it fails to start debugger on x64
binary
using VisualD?
Are you using VS2012 shell? I was experiencing the same
problem, that is a bug in the shell
On 17.10.2013 08:47, evilrat wrote:
On Thursday, 17 October 2013 at 06:42:58 UTC, Rainer Schuetze wrote:
On 16.10.2013 14:33, Bruno Medeiros wrote:
* How complete is the debugging info for DMD-Win64? Is it fully
implemented, and/or are there any issues or limitations? (Rainer you are
On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton wrote:
The strength of this is that it would allow us to freely
integrate D libraries that use std.logger, yet filter their log
output from *outside* the library through the std.logger API.
This is one of the most important aspects
On 2013-10-17 03:47, DDD wrote:
Does D have any reflection/introspection?
I'd like to do something like this
class Contact
{
string first, last
int number
}
contact = json_deserialized!Contact(json_string);
Is something like that possible?
If you need something more advanced you can try
On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton wrote:
On Tuesday, 15 October 2013 at 15:16:44 UTC, Andrei
Alexandrescu wrote:
Eric, could you please enumerate a short list of features of
log4j that you think would be really missed if absent?
Certainly. Here's my top 3, with some
On 2013-10-16 22:55, H. S. Teoh wrote:
Even *with* developer tools, where would you even start? I mean, the
blank page could have resulted from any one point of about 5kloc worth
of JS initialization code (which BTW dynamically loads in a whole bunch
of other JS code, each of which need to run
On 2013-10-16 23:08, Nick Sabalausky wrote:
Compiling it shouldn't be a problem:
http://xkcd.com/224/
So, it's written in Perl. That's why we haven't figured out how the
universe works:
You shoot yourself in the foot, but nobody can understand how you did
it. Six months later, neither can
On 10/17/2013 09:34 AM, qznc wrote:
On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton wrote:
The strength of this is that it would allow us to freely integrate D
libraries that use std.logger, yet filter their log output from
*outside* the library through the std.logger API.
This
On 10/16/2013 12:45 AM, Walter Bright wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=4151 does not contain the
info in your post starting this thread, nor does it contain any link to
this thread.
Yeah, more cross references please.
I personally dislike the DIP proliferation for anything
That one's working for me.
It still looks a little funny though:
; default to 32-bit linker (can generate 64-bit code) that has a common path
; for VS2010, VS2012, and VS2013. This will be overridden below if the
; installer detects VS.
LINKCMD=%VCINSTALLDIR%\bin\link.exe
;
On 10/13/2013 09:47 AM, Denis Shelomovskij wrote:
* Alex's one from MCI:
https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d
I remember talking about this with Alex.
He wanted to add some functions to the GC and this is what I came up
with
On 17 October 2013 17:08, Rainer Schuetze r.sagita...@gmx.de wrote:
On 16.10.2013 13:13, Manu wrote:
It seems the installer failed to replace two occurences of
%WindowsSdkDir%. WindowsSdkDir is set by batch files vsvars32.bat
and friends. I see conflicting goals here:
1.
On 10/17/2013 04:13 AM, Eric Anderton wrote:
On Tuesday, 15 October 2013 at 15:16:44 UTC, Andrei Alexandrescu wrote:
Eric, could you please enumerate a short list of features of log4j
that you think would be really missed if absent?
Certainly. Here's my top 3, with some background to explain
On Thursday, 17 October 2013 at 07:42:22 UTC, Jacob Carlborg
wrote:
On 2013-10-16 23:08, Nick Sabalausky wrote:
Compiling it shouldn't be a problem:
http://xkcd.com/224/
So, it's written in Perl. That's why we haven't figured out how
the universe works:
You shoot yourself in the foot, but
On 2013-10-17 11:15, Meta wrote:
So what's the D equivalent?
You're only allowed to shoot yourself in the foot if you use system.
From the comments:
D
You shoot yourself in the foot in two linse using a builtin Gun and
Bullet[].
The experience is so enjoyable you shoot yourself again….
On Thursday, 17 October 2013 at 09:49:37 UTC, Jacob Carlborg
wrote:
From the comments:
I had to laugh at this one:
.Net
Microsoft hands you a gun and swears blind it’s a toenail clipper
Someone throws a fucking chair at you.
17.10.2013 12:09, Martin Nowak пишет:
On 10/13/2013 09:47 AM, Denis Shelomovskij wrote:
* Alex's one from MCI:
https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d
I remember talking about this with Alex.
He wanted to add some functions to
+1
What can I say? For the web I have to use JavaScript, PHP and
Python. Imagine the amount of stupid-yet-hard-to-find bugs I've
had to deal with. Bugs that you only become aware of at runtime.
Am much happier with D (or Java, Objective-C). As for the
arguments concerning compile time,
On Thursday, 17 October 2013 at 07:43:07 UTC, Jacob Carlborg
wrote:
On 2013-10-16 22:55, H. S. Teoh wrote:
Even *with* developer tools, where would you even start? I
mean, the
blank page could have resulted from any one point of about
5kloc worth
of JS initialization code (which BTW
@Jacob Carlborg
I would say use structs. For compiler I would go with LDC or
GDC. Both of these are faster for floating point calculations
than DMD. You can always benchmark.
Thank you for the advice!
I installed ldc and used ldmd2.
Te benchmarks are amazing! :O
DMD compile = 2503 run =
On Thursday, 17 October 2013 at 13:54:34 UTC, PauloPinto wrote:
No debugger there to talk to the corresponding native browser
widgets. :( :(
Hm, some mobile browsers (e.g. Chrome on Android) come with
pretty tight remote debugging integration, maybe something like
that is available for
On 2013-10-17 15:54, PauloPinto wrote:
Unless you are developing a f hybrid application targeting to mobiles.
No debugger there to talk to the corresponding native browser widgets.
:( :(
You missed my other post about Firebug Lite:
Am 17.10.2013 16:26, schrieb David Nadlinger:
On Thursday, 17 October 2013 at 13:54:34 UTC, PauloPinto wrote:
No debugger there to talk to the corresponding native browser widgets.
:( :(
Hm, some mobile browsers (e.g. Chrome on Android) come with pretty tight
remote debugging integration,
Am 17.10.2013 17:03, schrieb Jacob Carlborg:
On 2013-10-17 15:54, PauloPinto wrote:
Unless you are developing a f hybrid application targeting to
mobiles.
No debugger there to talk to the corresponding native browser widgets.
:( :(
You missed my other post about Firebug Lite:
Róbert László Páli:
And would you suggest to try to use
SIMD double4 for 3D vectors? It would
take some time to change code.
Using a double4 could improve the performance of your code, but
it must be used wisely. (One general tip is to avoid mixing SIMD
and serial code. if you want to use
On Thursday, 17 October 2013 at 08:09:24 UTC, Martin Nowak wrote:
On 10/13/2013 09:47 AM, Denis Shelomovskij wrote:
* Alex's one from MCI:
https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d
I remember talking about this with Alex.
He wanted
On Oct 16, 2013, at 1:05 PM, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 16.10.2013 21:05, schrieb Sean Kelly:
On Oct 16, 2013, at 11:54 AM, Benjamin Thaut c...@benjamin-thaut.de wrote:
The problem is not that there are no GCs around in other languages which
satisfy certain
On Thursday, 17 October 2013 at 17:11:06 UTC, Sean Kelly wrote:
And even if this is doable in respect to DMD its going to be a
big problem for GDC or LDC to change the codegen.
Yes, any pointer anywhere. I recall someone posting a doc about
a compromise solution a few years back, but I'd have
Am 17.10.2013 19:16, schrieb David Nadlinger:
On Thursday, 17 October 2013 at 17:11:06 UTC, Sean Kelly wrote:
And even if this is doable in respect to DMD its going to be a big
problem for GDC or LDC to change the codegen.
Yes, any pointer anywhere. I recall someone posting a doc about a
On Thursday, 10 October 2013 at 12:39:00 UTC, Iain Buclaw wrote:
As part of the front-end harmonising work I'm doing, will be
adding in a Target hook to handle compiler-specific pragmas.
[…]
David, you OK with this? :-)
I can't speak for the other LDC devs, but I think this should be
fine.
On Thursday, 17 October 2013 at 17:28:17 UTC, Benjamin Thaut
wrote:
Am 17.10.2013 19:16, schrieb David Nadlinger:
But reading the part about the shadow stack really lowers my
expectations. Thats really something you don't want. The
performance impact is so going to be so big, that it doesn't
Am 17.10.2013 19:47, schrieb Sean Kelly:
On Thursday, 17 October 2013 at 17:28:17 UTC, Benjamin Thaut wrote:
Am 17.10.2013 19:16, schrieb David Nadlinger:
But reading the part about the shadow stack really lowers my
expectations. Thats really something you don't want. The performance
impact is
I expected slices to be in D (http://dlang.org/arrays.html) like
they are in Go
(http://blog.golang.org/go-slices-usage-and-internals). But they
are not.
Why the array have to be reallocated after the length of a slice
is changed? It makes slices useless.
Here a little example (it fails):
On Thursday, 17 October 2013 at 18:00:20 UTC, Vitali wrote:
I expected slices to be in D (http://dlang.org/arrays.html)
like they are in Go
(http://blog.golang.org/go-slices-usage-and-internals). But
they are not.
Why the array have to be reallocated after the length of a
slice is changed?
On Thursday, 17 October 2013 at 18:00:20 UTC, Vitali wrote:
I expected slices to be in D (http://dlang.org/arrays.html)
like they are in Go
(http://blog.golang.org/go-slices-usage-and-internals). But
they are not.
Why the array have to be reallocated after the length of a
slice is changed?
Hello Friends,
D How do you want to do with the event-based programming language
that has the support of D is
Thanks.
On Thursday, 17 October 2013 at 18:21:30 UTC, David Eagen wrote:
On Thursday, 17 October 2013 at 18:00:20 UTC, Vitali wrote:
I expected slices to be in D (http://dlang.org/arrays.html)
like they are in Go
(http://blog.golang.org/go-slices-usage-and-internals). But
they are not.
Why the
On 10/17/2013 11:00 AM, Vitali wrote:
I expected slices to be in D (http://dlang.org/arrays.html)
There is also this article:
http://dlang.org/d-array-article.html
like they
are in Go (http://blog.golang.org/go-slices-usage-and-internals). But
they are not.
Every design comes with pros
On Thursday, 17 October 2013 at 18:29:47 UTC, John Colvin wrote:
On Thursday, 17 October 2013 at 18:00:20 UTC, Vitali wrote:
I expected slices to be in D (http://dlang.org/arrays.html)
like they are in Go
(http://blog.golang.org/go-slices-usage-and-internals). But
they are not.
Why the
On Wednesday, 16 October 2013 at 08:56:26 UTC, John Colvin wrote:
On Tuesday, 15 October 2013 at 21:51:06 UTC, Timothee Cour
wrote:
I've done it using swig, and using C++ api (not C api), as
well as for
other libs (sfml etc). it requires a bit of tweaking the '.i'
file but is
doable. Much
On Thursday, 17 October 2013 at 18:41:53 UTC, Vitali wrote:
arr = arr[0..index] ~ arr[index+1..$];
This line is where the reallocation happens. a ~ b on built in
arrays and slices, ALWAYS allocates to ensure it doesn't stomp
over some other in-use memory.
~= can extend if there's
On 10/17/2013 11:41 AM, Vitali wrote:
On Thursday, 17 October 2013 at 18:29:47 UTC, John Colvin wrote:
On Thursday, 17 October 2013 at 18:00:20 UTC, Vitali wrote:
I expected slices to be in D (http://dlang.org/arrays.html) like they
are in Go
On Thursday, 17 October 2013 at 18:00:20 UTC, Vitali wrote:
I expected slices to be in D (http://dlang.org/arrays.html)
like they are in Go
(http://blog.golang.org/go-slices-usage-and-internals). But
they are not.
Why the array have to be reallocated after the length of a
slice is changed?
dSlice says that it has length 2,
That's before appending an element.
but accessing dSlice[2] does not
produce a RangeError...
That's after appending an element.
Ali
On Thursday, October 17, 2013 20:31:26 Vitali wrote:
I repeat my question: Why does a reallocation accure AFTER a
resize of the length of a slice, although there is still
capacity?
Because it _doesn't_ have the capacity. If you do
writeln(dSlice.capacity);
before incrementing dSlice's
On Thursday, 17 October 2013 at 18:51:08 UTC, Meta wrote:
As David Eagen said, your problem is that in D, dArr[0..2] is
not inclusive, it's exclusive, so you get dArr[0] and dArr[1].
Changing it to dSlice = dArr[0..3] will work (or better,
dArr[0..$]). However, there's something else going on
vibed.org
On Thursday, 17 October 2013 at 08:08:08 UTC, Manu wrote:
That one's working for me.
It still looks a little funny though:
This is all behaving as intended. I'll explain below.
; default to 32-bit linker (can generate 64-bit code) that has
a common path
; for VS2010, VS2012, and VS2013.
I didn't expect that you would doubt that the array gets
reallocated. Here a code to test:
void appendElement(ref int[] arr, int x) {
arr ~= x;
}
void removeElement(ref int[] arr, int index) {
arr = arr[0..index] ~ arr[index+1..$];
}
void main() {
int* arrPtr1;
int*
On Thursday, 17 October 2013 at 07:15:48 UTC, Rainer Schuetze
wrote:
On 17.10.2013 01:49, Manu wrote:
On 17 October 2013 02:51, dnewbie r...@myopera.com
mailto:r...@myopera.com wrote:
1. 64-bit link.exe:
C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\Bin\amd64\link.exe
2.
On Thursday, October 17, 2013 21:23:36 Vitali wrote:
@Meta and @David Eagen: My question is not about creating slices,
but about make them shrink and grow without reallocating the
referenced array.
The only way to make a slice grow and slice more of the array that it was a
slice of is to
On Thursday, 17 October 2013 at 19:23:37 UTC, Vitali wrote:
I'm not accusing D having a bug here. I'm saying that in my
eyes a reallocation of the array referenced by the slice is not
useful, when capacity is still available.
There is no capacity available for the binary concatenation like
On Thursday, 17 October 2013 at 18:00:20 UTC, Vitali wrote:
int[] dArr = [10, 11, 12];
int[] dSlice = dArr[0..2];
Oh, and there is no difference between dynamic arrays and slices
of them in D (as shown by the fact that the type is the same).
David
On Thursday, 17 October 2013 at 18:00:20 UTC, Vitali wrote:
Why the array have to be reallocated after the length of a
slice is changed? It makes slices useless.
No, it doesn't. They are extremely helpful, particularly for
high-performance applications.
Here a little example (it fails):
On Thursday, 17 October 2013 at 18:41:53 UTC, Vitali wrote:
void removeElement(ref int[] arr, int index) {
arr = arr[0..index] ~ arr[index+1..$];
}
If you know that 'arr' is the only reference to this piece of
data, you can use arr.assumeSafeAppend() to enable re-use of the
remaining
On Thursday, 17 October 2013 at 19:05:32 UTC, Jonathan M Davis
wrote:
before incrementing dSlice's length, it'll print out 0. dSlice
can't grow in
place, because if it did, its new elements would overlap with
those of dArr;
dArr - [10, 11, 12]
dSlice - [10, 11]
Well this is only one part
On Thursday, 17 October 2013 at 19:23:37 UTC, Vitali wrote:
I repeat [...] as efficient as manipulating array indices. In
D this is not the case and can't imagine what purpose can it
suit else.
This is also the case for D.
Without knowing the Go design in detail, I'd say the major
On Thursday, 17 October 2013 at 20:01:37 UTC, David Nadlinger
wrote:
On Thursday, 17 October 2013 at 18:41:53 UTC, Vitali wrote:
void removeElement(ref int[] arr, int index) {
arr = arr[0..index] ~ arr[index+1..$];
}
If you know that 'arr' is the only reference to this piece of
data, you
1 - 100 of 197 matches
Mail list logo
