Till we have such issues
http://forum.dlang.org/thread/mailman.357.1384163617.9546.digitalmar...@puremagic.com
I think we should have native replacement.
On Thursday, 28 November 2013 at 16:24:34 UTC, Adam D. Ruppe
wrote:
On Thursday, 28 November 2013 at 11:37:45 UTC, Jonas Drewsen
wrote:
I definitely agree. In addition D has obtained some nice
features since the definition of the std.net.curl API that I
would liked have used back then.
What a
On 11/27/2013 12:07 AM, Andrei Alexandrescu wrote:
My conclusion after this whole discussion: in the short term we need to
have both Fedora and Debian builds. Then we'll move from there.
Right, different distributions => different shared libraries.
On 11/29/13 5:47 AM, Jacob Carlborg wrote:
On 2013-11-29 03:39, Andrei Alexandrescu wrote:
We'll probably keep it but not advertise it. But you're making a
terrible argument - you want us to keep a bankrupt artifact just because
you don't want to update your code.
That's the standard argument
On Tuesday, 26 November 2013 at 19:21:31 UTC, Andrei Alexandrescu
wrote:
On 11/26/13 11:13 AM, Iain Buclaw wrote:
Remembering to include '-lcurl' when importing std.net.curl is
perhaps
one urk. But this will be a no longer a problem if libphobos
is built
shared.
Interesting. Can we supply a
On 2013-11-29 03:39, Andrei Alexandrescu wrote:
We'll probably keep it but not advertise it. But you're making a
terrible argument - you want us to keep a bankrupt artifact just because
you don't want to update your code.
That's the standard argument, "can't remove/change this, will break
bac
On Thursday, November 28, 2013 21:23:33 Jacob Carlborg wrote:
> On 2013-11-28 20:17, Jonathan M Davis wrote:
> > The zip has nothing to do with the stability of D itself. It just has to
> > do
> > with the stalibity of how D is distributed, which is a completely
> > different
> > issue. I can see w
On 11/28/13 12:21 PM, Jacob Carlborg wrote:
On 2013-11-28 19:25, Marco Leise wrote:
Don't be so ignorant. The zip is broken for all Linux systems
bug Debian. I thought that with D Version Manager you tried to
support more than one Linux distribution...
Yes, I would like that. But if the the c
On 2013-11-28 19:25, Marco Leise wrote:
Don't be so ignorant. The zip is broken for all Linux systems
bug Debian. I thought that with D Version Manager you tried to
support more than one Linux distribution...
Yes, I would like that. But if the the current zip is removed it will
break _every_
On 2013-11-28 20:44, H. S. Teoh wrote:
I don't see what's the big deal with providing one zip per supported
platform (and each Linux distro is to be considered a separate platform
here), *and* a dmd_everything.zip for distributors who *want* to have
everything in one (they are installing D onto
On 2013-11-28 20:17, Jonathan M Davis wrote:
The zip has nothing to do with the stability of D itself. It just has to do
with the stalibity of how D is distributed, which is a completely different
issue. I can see why you care about the zip, given that you wrote and maintain
a tool which relies
On 2013-11-28 15:51, Dicebot wrote:
We can leave old .zip as-is just make it explicit that it is legacy
layout and only 100% expected to work on Debian-compatible distros. I
really don't care how it is distributed as I am using git tag anyway -
what I do care about are users having wrong expecta
On Thu, Nov 28, 2013 at 11:29:04AM -0800, Andrei Alexandrescu wrote:
[...]
> Besides the fundamental point remains. People don't need to download
> all platform files on one platform. It just doesn't follow. And the
> larger the distribution will become the more annoying the issue will
> be.
[...]
On 11/28/13 11:17 AM, Jonathan M Davis wrote:
On Thursday, November 28, 2013 08:36:08 Jacob Carlborg wrote:
On 2013-11-27 21:46, Dicebot wrote:
Distributing binaries for Mac and Windows is fine (though it is much
better to keep those separate archives and patch DVM accordingly), this
thread is
On Thursday, November 28, 2013 08:36:08 Jacob Carlborg wrote:
> On 2013-11-27 21:46, Dicebot wrote:
> > Distributing binaries for Mac and Windows is fine (though it is much
> > better to keep those separate archives and patch DVM accordingly), this
> > thread is about Linux ones. You did not have a
Am Wed, 27 Nov 2013 21:08:20 +0100
schrieb Jacob Carlborg :
> I mean that I like the current zip to stay.
Don't be so ignorant. The zip is broken for all Linux systems
bug Debian. I thought that with D Version Manager you tried to
support more than one Linux distribution...
--
Marco
El 28/11/13 18:17, Adam D. Ruppe ha escrit:
> On Thursday, 28 November 2013 at 17:12:25 UTC, Jordi Sayol wrote:
>> Please can you show something on dmd/phobos that fails on any actively
>> maintained Linux distro that properly works on another one?
>
> The dmd zip doesn't work on CentOS 5 because
On Thursday, 28 November 2013 at 17:12:25 UTC, Jordi Sayol wrote:
Please can you show something on dmd/phobos that fails on any
actively maintained Linux distro that properly works on another
one?
The dmd zip doesn't work on CentOS 5 because of a libc version
mismatch, so it has to be recompi
El 28/11/13 17:12, Dicebot ha escrit:
> On Thursday, 28 November 2013 at 15:59:12 UTC, Jordi Sayol wrote:
>> We should then generate dmd packages for every distro release because they
>> can fail between releases too.
>
> Or just let specific distro package maintainers do their job.
>
>> The onl
On Thursday, 28 November 2013 at 11:37:45 UTC, Jonas Drewsen
wrote:
I definitely agree. In addition D has obtained some nice
features since the definition of the std.net.curl API that I
would liked have used back then.
What are you thinking of there? I think plain old classes and
delegates ar
On Thursday, 28 November 2013 at 15:59:12 UTC, Jordi Sayol wrote:
We should then generate dmd packages for every distro release
because they can fail between releases too.
Or just let specific distro package maintainers do their job.
The only thing that breaks the current dmd zip system is
li
El 27/11/13 13:56, Dicebot ha escrit:
> On Tuesday, 26 November 2013 at 21:04:31 UTC, Andrei Alexandrescu wrote:
>>> I really think providing just source + single additional .deb package as
>>> an example is the best way to go.
>>
>> Well we kind of do that already. No?
>>
>> Andrei
>
> No. We pro
El 26/11/13 19:44, Andrei Alexandrescu ha escrit:
> On 11/25/13 4:36 PM, Adam D. Ruppe wrote:
>> On Tuesday, 26 November 2013 at 00:13:57 UTC, Andrei Alexandrescu wrote:
>>> First I'd like to gather an understanding on why we seem to have this
>>> problem (far as I understand, the likes of php and
On Thursday, 28 November 2013 at 07:36:09 UTC, Jacob Carlborg
wrote:
On 2013-11-27 21:46, Dicebot wrote:
Distributing binaries for Mac and Windows is fine (though it
is much
better to keep those separate archives and patch DVM
accordingly), this
thread is about Linux ones. You did not have any
On Wednesday, 27 November 2013 at 01:32:18 UTC, Jonathan M Davis
wrote:
On Wednesday, November 27, 2013 02:05:39 Adam D. Ruppe wrote:
...unless doing a new interface is on the table too. Then, we
can
leave std.net.curl exactly how it is, so people who use it
don't
have broken code, while a new
On 2013-11-27 21:46, Dicebot wrote:
Distributing binaries for Mac and Windows is fine (though it is much
better to keep those separate archives and patch DVM accordingly), this
thread is about Linux ones. You did not have any problems with it
because Debian derivatives take major percentage of u
On 26.11.2013 20:01, Andrei Alexandrescu wrote:
>> I'm for removing as I always compile Phobos without curl anyway (I don't
>> want to install all dependencies).
>
> So then why are you bothered? Are you willing to break a lot of people's
> code because you don't need this feature?
I'm not that b
On Wednesday, 27 November 2013 at 14:16:33 UTC, Adam D. Ruppe
wrote:
(The biggest pain with clients btw? Buggy servers! It has
gotten a little better, but when I started with this, Twitter,
LinkedIn, and AWeber, the three I had to use all
interpreted the spec slightly differently, so what w
On Wednesday, 27 November 2013 at 20:06:52 UTC, Jacob Carlborg
wrote:
On 2013-11-27 20:13, Dicebot wrote:
DVM is already broken if it relies on binaries present in .zip
We can't claim that we support things that we don't actually
support
It works perfectly fine on Mac OS X and Windows. No ne
On Wednesday, 27 November 2013 at 20:05:29 UTC, Jacob Carlborg
wrote:
On 2013-11-27 20:13, Dicebot wrote:
DVM is already broken if it relies on binaries present in .zip
We can't claim that we support things that we don't actually
support
So we don't support the zip we release every time?
Y
On 2013-11-27 20:13, Dicebot wrote:
DVM is already broken if it relies on binaries present in .zip
We can't claim that we support things that we don't actually support
It works perfectly fine on Mac OS X and Windows. No need to break it on
all platforms just because one platform is broken. I
On 2013-11-27 19:58, Andrei Alexandrescu wrote:
Wait, you mean with binaries and all?
I mean that I like the current zip to stay.
--
/Jacob Carlborg
On 2013-11-27 20:13, Dicebot wrote:
DVM is already broken if it relies on binaries present in .zip
We can't claim that we support things that we don't actually support
So we don't support the zip we release every time?
--
/Jacob Carlborg
On Wednesday, 27 November 2013 at 19:10:26 UTC, Adam D. Ruppe
wrote:
On Wednesday, 27 November 2013 at 18:58:42 UTC, Andrei
Alexandrescu wrote:
Wait, you mean with binaries and all?
Yeah, I like it the way it is too since I use the binaries too,
building windows programs from my linux box cal
On Wednesday, 27 November 2013 at 18:58:42 UTC, Andrei
Alexandrescu wrote:
Wait, you mean with binaries and all?
Yeah, I like it the way it is too since I use the binaries too,
building windows programs from my linux box calling wine dmd. My
scripts currently assume the zip layout and it work
On Wednesday, 27 November 2013 at 18:57:23 UTC, Jacob Carlborg
wrote:
On 2013-11-27 19:00, Andrei Alexandrescu wrote:
I agree the business with distributing all binaries for all
platforms in
the .zip is just weird. We should drop it for the New Year's
release.
I would hate to see the cross-p
On Wednesday, 27 November 2013 at 18:16:34 UTC, H. S. Teoh wrote:
Didn't Nick already write a script that would generate separate
tarballs
/ zipballs / whatnot for each supported platform?
It still implies that "Linux xx-bit" is a single platform which
is not true.
On Wed, Nov 27, 2013 at 07:45:07PM +0100, John Colvin wrote:
> On Wednesday, 27 November 2013 at 17:58:48 UTC, Andrei Alexandrescu
> wrote:
[...]
> >We could add that. I'll note that building Phobos is something for
> >the experts only.
> >
> >Andrei
>
> I'm not sure I would consider myself an exp
On 11/27/13 10:57 AM, Jacob Carlborg wrote:
On 2013-11-27 19:00, Andrei Alexandrescu wrote:
I agree the business with distributing all binaries for all platforms in
the .zip is just weird. We should drop it for the New Year's release.
I would hate to see the cross-platform zip gone. It would
On 2013-11-27 19:15, H. S. Teoh wrote:
Didn't Nick already write a script that would generate separate tarballs
/ zipballs / whatnot for each supported platform?
Yes, https://github.com/D-Programming-Language/installer/pull/24
--
/Jacob Carlborg
On 2013-11-27 19:00, Andrei Alexandrescu wrote:
I agree the business with distributing all binaries for all platforms in
the .zip is just weird. We should drop it for the New Year's release.
I would hate to see the cross-platform zip gone. It would break DVM and
probably other tools/scripts.
On Wednesday, 27 November 2013 at 17:58:48 UTC, Andrei
Alexandrescu wrote:
On 11/27/13 2:26 AM, Martin Krejcirik wrote:
On 26.11.2013 20:02, Andrei Alexandrescu wrote:
(0x7f28ca047000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(0x7f28c9e2b000)
/lib64/ld-linux-x86-
On Wed, Nov 27, 2013 at 10:00:38AM -0800, Andrei Alexandrescu wrote:
> On 11/27/13 4:56 AM, Dicebot wrote:
[...]
> >No. We provide Linux binaries in .zip and pretend they are expected
> >to work for all distros which simply can't happen in general. Fedora
> >bug report would not have been valid if
On 11/27/13 4:56 AM, Dicebot wrote:
On Tuesday, 26 November 2013 at 21:04:31 UTC, Andrei Alexandrescu wrote:
I really think providing just source + single additional .deb package as
an example is the best way to go.
Well we kind of do that already. No?
Andrei
No. We provide Linux binaries i
On 11/27/13 2:26 AM, Martin Krejcirik wrote:
On 26.11.2013 20:02, Andrei Alexandrescu wrote:
(0x7f28ca047000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(0x7f28c9e2b000)
/lib64/ld-linux-x86-64.so.2 (0x7f28cd28e000)
libtasn1.so.3 => /usr/lib/x86_64-linux-g
On Wednesday, 27 November 2013 at 08:45:37 UTC, Andrea Fontana
wrote:
Should we consider interoperability with std.path too?
Generally, I think no, though it would be easy enough to get
uri.path as a decoded string and pass it to those functions.
But std.path is a bit different on Windows an
On Wednesday, 27 November 2013 at 14:07:02 UTC, Wyatt wrote:
Make it a proper dep and let the distro packagers do what they
do best. The --without-curl switch is a good idea, btw.
Distro packagers don't have any issues even now (assuming they
build stuff locally). It is all about "official" .
On Wednesday, 27 November 2013 at 10:26:50 UTC, Martin Krejcirik
wrote:
The problem (in my case) is, that you also need to install the
-dev
packages of these libraries just to compile Phobos (even if you
don't
use curl in your programs at all).
As usual, -dev packages just make life worse fo
On Wednesday, 27 November 2013 at 07:39:17 UTC, Jacob Carlborg
wrote:
Doesn't GnuTLS provide an OpenSSL API?
idk. If so, that's easy. I've just seen curl compiled separately
for gnutls and openssl so I assumed they must be different.
Nevertheless, I really think dynamic linking is the way to
On 2013-11-27 11:26, Martin Krejcirik wrote:
The problem (in my case) is, that you also need to install the -dev
packages of these libraries just to compile Phobos (even if you don't
use curl in your programs at all).
Maybe we just need something like --without-curl for Phobos makefile.
That'
On Tuesday, 26 November 2013 at 21:04:31 UTC, Andrei Alexandrescu
wrote:
I really think providing just source + single additional .deb
package as
an example is the best way to go.
Well we kind of do that already. No?
Andrei
No. We provide Linux binaries in .zip and pretend they are
expecte
On 26.11.2013 20:02, Andrei Alexandrescu wrote:
>> (0x7f28ca047000)
>> libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
>> (0x7f28c9e2b000)
>> /lib64/ld-linux-x86-64.so.2 (0x7f28cd28e000)
>> libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3
>> (0x7f28c9c1a
On Wednesday, 27 November 2013 at 04:09:53 UTC, Adam D. Ruppe
wrote:
On Wednesday, 27 November 2013 at 01:30:26 UTC, Andrei
Alexandrescu wrote:
A new interface is also on the table, but that brings the
additional burden of defining your own design. std.net.curl
has already been approved.
Aye,
On 2013-11-27 05:09, Adam D. Ruppe wrote:
2) Some kind of SSL sockets, including adding ssl to an already
open socket (needed for STARTTLS on smtp at least). I did a
partial implementation as a subclass of Phobos' Socket with
openssl. Should also do a Windows impl and probably a gnutls as
well.
On Wednesday, 27 November 2013 at 01:30:26 UTC, Andrei
Alexandrescu wrote:
A new interface is also on the table, but that brings the
additional burden of defining your own design. std.net.curl has
already been approved.
Aye, but that'd be worth it. There's a few pieces we should get
together:
Am Tue, 26 Nov 2013 12:04:59 -0800
schrieb Andrei Alexandrescu :
> What flags are we requiring for use with std.net.curl? Are those
> depending on what specific calls are being used (e.g. using https etc)?
> We could document that stuff. All in all it doesn't seem unreasonable to
> me to requir
Am Tue, 26 Nov 2013 11:02:06 -0800
schrieb Andrei Alexandrescu :
> On 11/25/13 6:22 PM, Jordi Sayol wrote:
> > On Debian testing (64-bit):
> >
> > $ ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0
> > linux-vdso.so.1 (0x7fff36519000)
> > libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.
On Wednesday, 27 November 2013 at 01:40:15 UTC, Mike Parker wrote:
This problem would be solved by going with a dynamic binding
for libcurl rather than a static binding. Then std.net.curl
could load libcurl on demand and it doesn't matter how it was
compiled (unless, of course, the libcurl API
On 11/27/2013 6:12 AM, David Nadlinger wrote:
On Tuesday, 26 November 2013 at 21:04:31 UTC, Andrei Alexandrescu wrote:
On 11/26/13 12:21 PM, Dicebot wrote:
I really think providing just source + single additional .deb package as
an example is the best way to go.
Well we kind of do that alread
On 11/26/13 5:05 PM, Adam D. Ruppe wrote:
On Wednesday, 27 November 2013 at 00:19:31 UTC, Andrei Alexandrescu wrote:
Care to make it interesting? I may have some funds for this. But we're
looking for no less than a glorious 100% replacement.
Meh, my first choice is still to just bundle curl wi
On Wednesday, November 27, 2013 02:05:39 Adam D. Ruppe wrote:
> ...unless doing a new interface is on the table too. Then, we can
> leave std.net.curl exactly how it is, so people who use it don't
> have broken code, while a new std.net.http, std.net.smtp,
> std.net.ftp, and so on are phased in for
Am Tue, 26 Nov 2013 10:44:07 -0800
schrieb Andrei Alexandrescu :
> On 11/25/13 4:36 PM, Adam D. Ruppe wrote:
> > On Tuesday, 26 November 2013 at 00:13:57 UTC, Andrei Alexandrescu wrote:
> >> First I'd like to gather an understanding on why we seem to have this
> >> problem (far as I understand, th
On Wednesday, 27 November 2013 at 00:49:57 UTC, H. S. Teoh wrote:
Sounds like the perfect job for a quick-n-dirty D program,
right?
Oh yeah, my http.d and dom.d can make short work of that. I had a
similar problem last year and ended up getting it to work very
easily (well, that one used my c
On Wednesday, 27 November 2013 at 00:19:31 UTC, Andrei
Alexandrescu wrote:
Care to make it interesting? I may have some funds for this.
But we're looking for no less than a glorious 100% replacement.
Meh, my first choice is still to just bundle curl with phobos,
like we do with zlib. It seems
On Tue, Nov 26, 2013 at 04:19:31PM -0800, Andrei Alexandrescu wrote:
> On 11/26/13 3:40 PM, Adam D. Ruppe wrote:
> >Again though, my position is that curl is ok and I use it myself, but
> >let's not assume we need the entire kitchen sink that curl offers,
> >especially given the fact that std.net.c
On 11/26/13 3:40 PM, Adam D. Ruppe wrote:
Again though, my position is that curl is ok and I use it myself, but
let's not assume we need the entire kitchen sink that curl offers,
especially given the fact that std.net.curl barely scratches it anyway.
If someone does need one of curl's less common
On Tuesday, 26 November 2013 at 23:05:08 UTC, Andrei Alexandrescu
wrote:
That's quite a claim to make.
If you've used HTTP, you'll know how true it is. Indeed, since a
request consists solely of a request and a body, being able to
change them by definition gives you full access!
The most co
On Monday, 25 November 2013 at 07:38:38 UTC, Jordi Sayol wrote:
As Jonathan M Davis said:
---
Several of the main devs (including Walter) have stated that
having std.net.curl on Phobos was a mistake given all of the
problems that we've had with it on Windows and Linux as well,
and at least som
On 11/26/13 3:03 PM, deadalnix wrote:
In some cases, it can prevent the whole stuff to link.
This is very vague. Are there cases in which something NOT using
std.net.curl fails to link?
Otherwise, hello world should simply work.
I guess that's where we want it.
My conclusion after this w
On 11/26/13 2:04 PM, Adam D. Ruppe wrote:
On Tuesday, 26 November 2013 at 21:33:50 UTC, Jonas Drewsen wrote:
But have a look at the libcurl API docs and think about how many lines
it would take to implement that in D.
Meh, I don't think I've ever needed any of it. Set header and request
data i
On Tuesday, 26 November 2013 at 19:06:26 UTC, Andrei Alexandrescu
wrote:
On 11/25/13 10:53 PM, H. S. Teoh wrote:
On Tue, Nov 26, 2013 at 06:44:03AM +0100, Jesse Phillips wrote:
[...]
I don't think I understand having to build dmd just because
you have
a different distribution, Phobos maybe but
On 11/26/13 12:24 PM, Dmitry Olshansky wrote:
26-Nov-2013 23:40, Andrei Alexandrescu пишет:
On 11/26/13 11:23 AM, Dmitry Olshansky wrote:
See some hilarious things I had to do to link it properly:
https://github.com/blackwhale/tools/blob/master/posix.mak#L35
Interesting. Never knew of the pat
On Tuesday, 26 November 2013 at 21:33:50 UTC, Jonas Drewsen wrote:
But have a look at the libcurl API docs and think about how
many lines it would take to implement that in D.
Meh, I don't think I've ever needed any of it. Set header and
request data is enough to do anything on http.
On 11/26/13 1:33 PM, Jonas Drewsen wrote:
On Tuesday, 26 November 2013 at 21:23:05 UTC, Adam D. Ruppe wrote:
On Tuesday, 26 November 2013 at 16:39:50 UTC, Andrei Alexandrescu wrote:
The problem is that "long ago" adding libcurl seemed like a perfectly
reasonable option, particularly considering
On Tuesday, 26 November 2013 at 21:23:05 UTC, Adam D. Ruppe wrote:
On Tuesday, 26 November 2013 at 16:39:50 UTC, Andrei
Alexandrescu wrote:
The problem is that "long ago" adding libcurl seemed like a
perfectly reasonable option, particularly considering that we
didn't (and we don't) have anythi
On Tuesday, 26 November 2013 at 16:39:50 UTC, Andrei Alexandrescu
wrote:
The problem is that "long ago" adding libcurl seemed like a
perfectly reasonable option, particularly considering that we
didn't (and we don't) have anything to replace it.
Meh, doing the http and smtp stuff isn't rocket
Personally I have always thought of std.net.curl as a temporary
solution until a native implementation in D could be created. But
I was also fully aware that people were not standing in line to
make a native one and that we needed something else in the
meantime. That is why I implemented it in
On Tuesday, 26 November 2013 at 21:12:23 UTC, Andrea Fontana
wrote:
On Tuesday, 26 November 2013 at 19:40:10 UTC, Andrei
Alexandrescu wrote:
[...] and presumably quite a few people who do use
std.net.curl without troubles and don't know we plan to pull
the plug on it. [...]
That's me! It wo
On 11/26/13 12:06 PM, Jacob Carlborg wrote:
As many have mentioned before. Everything (in this case
Phobos) should
be built on the same platform as it is shipping. So we needed
specific
releases for each Linux distribution we want to support.
On Tuesday, 26 November 2013 at 20:10:19 UTC, Andr
On Tuesday, 26 November 2013 at 21:04:31 UTC, Andrei Alexandrescu
wrote:
On 11/26/13 12:21 PM, Dicebot wrote:
I really think providing just source + single additional .deb
package as
an example is the best way to go.
Well we kind of do that already. No?
The issue is (mainly) with people exp
On Tuesday, 26 November 2013 at 19:40:10 UTC, Andrei Alexandrescu
wrote:
[...] and presumably quite a few people who do use std.net.curl
without troubles and don't know we plan to pull the plug on it.
[...]
That's me! It works for me and my company.
On 11/26/13 12:21 PM, Dicebot wrote:
On Tuesday, 26 November 2013 at 20:10:19 UTC, Andrei Alexandrescu wrote:
As many have mentioned before. Everything (in this case Phobos) should
be built on the same platform as it is shipping. So we needed specific
releases for each Linux distribution we want
On Tuesday, 26 November 2013 at 19:13:40 UTC, Iain Buclaw wrote:
Remembering to include '-lcurl' when importing std.net.curl is
perhaps
one urk. But this will be a no longer a problem if libphobos
is built
shared.
Isn't that like -lm for C programs? Doesn't seem big to me.
On Tuesday, 26 November 2013 at 20:10:19 UTC, Andrei Alexandrescu
wrote:
As many have mentioned before. Everything (in this case
Phobos) should
be built on the same platform as it is shipping. So we needed
specific
releases for each Linux distribution we want to support.
OK, thanks. That seem
26-Nov-2013 23:40, Andrei Alexandrescu пишет:
On 11/26/13 11:23 AM, Dmitry Olshansky wrote:
For the moment it looks as if half people are pissed off because of the
work they would need to do on it (workaround, shipping, maintenance,
etc.), and the other half (using it) are having usability probl
On 2013-11-26 21:04, Andrei Alexandrescu wrote:
What flags are we requiring for use with std.net.curl? Are those
depending on what specific calls are being used (e.g. using https etc)?
We could document that stuff. All in all it doesn't seem unreasonable to
me to require certain specifics for us
On 2013-11-26 18:58, Iain Buclaw wrote:
Especially when you look at the "competitors"
http://curl.haxx.se/libcurl/competitors.html
The checkboxes that would need to be ticked for me:
1. Does it have any third party dependencies? Preferably no.
2. Can it be built into libphobos easily - see:
On 2013-11-26 21:10, Andrei Alexandrescu wrote:
OK, thanks. That seems like something approachable from our end. Is this
a common approach among other language distributions, e.g. python, ruby,
go, rust etc. etc? What is a list of platforms we need to support?
Yes, that's always the preferred
On 11/26/13 12:06 PM, Jacob Carlborg wrote:
On 2013-11-26 20:00, Andrei Alexandrescu wrote:
So what is the classic recommended solution for such cases? We can't be
the first people who are having this issue on Unix.
As many have mentioned before. Everything (in this case Phobos) should
be bui
On 2013-11-26 20:00, Andrei Alexandrescu wrote:
So what is the classic recommended solution for such cases? We can't be
the first people who are having this issue on Unix.
As many have mentioned before. Everything (in this case Phobos) should
be built on the same platform as it is shipping. S
On 11/26/13 11:57 AM, Dicebot wrote:
On Tuesday, 26 November 2013 at 19:29:02 UTC, Andrei Alexandrescu wrote:
There is no such thing as _The_ curl library. Different distros may have
versions with incompatible symbol versioning installed - this is the
very issue with Fedora which was actively di
On Tuesday, 26 November 2013 at 20:02:29 UTC, Andrei Alexandrescu
wrote:
On 11/26/13 11:56 AM, Brad Anderson wrote:
On Tuesday, 26 November 2013 at 19:27:07 UTC, Andrei
Alexandrescu wrote:
On 11/26/13 11:13 AM, Brad Anderson wrote:
To use 32-bit curl you need to generate an OMF import
library
On 11/26/13 11:56 AM, Brad Anderson wrote:
On Tuesday, 26 November 2013 at 19:27:07 UTC, Andrei Alexandrescu wrote:
On 11/26/13 11:13 AM, Brad Anderson wrote:
To use 32-bit curl you need to generate an OMF import library from the
libcurl DLL. It's not terribly hard. I did it originally for when
On Tuesday, 26 November 2013 at 19:27:07 UTC, Andrei Alexandrescu
wrote:
On 11/26/13 11:13 AM, Brad Anderson wrote:
To use 32-bit curl you need to generate an OMF import library
from the
libcurl DLL. It's not terribly hard. I did it originally for
when I
added downloading of libcurl to the Win
On 2013-11-26 20:13, Brad Anderson wrote:
If I remember correctly Walter didn't want to distribute in the dmd zip
anything that wasn't boost licensed which is why curl on Windows comes
as a separate download. zlib is a notable exception but I seem to recall
Walter regretted including zlib.
The
On Tuesday, 26 November 2013 at 19:29:02 UTC, Andrei Alexandrescu
wrote:
There is no such thing as _The_ curl library. Different
distros may have
versions with incompatible symbol versioning installed - this
is the
very issue with Fedora which was actively discussed in
bugzilla.
But can't we
On 2013-11-26 20:27, Andrei Alexandrescu wrote:
When is the OMF library needed?
1. While building dmd
2. While building druntime
3. While building phobos
4. While building client code that does NOT use std.net.curl
5. While building client code that DOES use std.net curl
Not that I have t
On Tuesday, 26 November 2013 at 19:43:02 UTC, Andrei Alexandrescu
wrote:
This is pretty awesome. Is @brocolis around on this forum?
Andrei
I'm not sure. He goes by dnewbie/dnwbie on IRC.
On Tuesday, 26 November 2013 at 17:58:46 UTC, Iain Buclaw wrote:
sqllite3.amalgamation.c which I thought *was* in phobos at some
point... maybe not?
I had done work in that regard, but it was decided that it
shouldn't be added so Phobos didn't ship with old versions that
had known security bu
On 11/26/13 11:39 AM, Brad Anderson wrote:
On Tuesday, 26 November 2013 at 19:23:54 UTC, Dmitry Olshansky wrote:
https://d.puremagic.com/issues/show_bug.cgi?id=7044
This is a constant annoyance of mine using std.net.curl on Linux.
Now if that doesn't set off the alarms. Win32/64 curl librar
1 - 100 of 142 matches
Mail list logo
