On Friday, 18 October 2013 at 04:14:59 UTC, deadalnix wrote:
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 affe
code.dlang.org
Does we should have cats? maybe the organization by tags is
better?
On 2013-10-17 22:35, Andrej Mitrovic wrote:
- Walter is still not tagging the beta releases by the file name (it's
always dmd2beta.zip). I've complained about this several times and
IIRC someone else did as well at dconf (maybe I'm remembering wrong
though). They should at least be named as "dmd
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 closu
On 10/16/13, Brad Roberts 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
major plans ahead, e.g.
On Thursday, 17 October 2013 at 18:22:02 UTC, Sönke Ludwig wrote:
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
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, p
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 target
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 main/super
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
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 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,
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" wrote:
> 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 c
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 i
Am 17.10.2013 15:31, schrieb Jacob Carlborg:
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
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 lice
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 cod
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 existi
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 code. I don't know if that's possible in Dub, bu
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 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 package.
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
On 10/17/13, Sönke Ludwig 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 th
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: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 packag
On 10/17/13, Sönke Ludwig 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 rejected because it's missin
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 t
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 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 freq
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 licen
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 p
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 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 lic
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 sp
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 branches and version
tags stay unaff
On 2013-10-17 09:42, Timothee Cour wrote:
on OSX, lldb has better support than gdb.
Not for D. Break points doesn't work in LLDB but they do work in GDB.
The backtrace seem to be slightly incorrect as well. The line number for
frame 0 is off by one. Printing a variable doesn't seem to work.
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
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 what
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
38 matches
Mail list logo
