On 2015-06-03 09:43, Dan Olson wrote:

> Not yet.  I greedily work on puzzles I think I can solve..

But since you have patched LLVM you have already solved the issue ;)

> On the other
> hand, a Rust dev last year was able to use the iOS TLS patch to LLVM and
> perhaps made some progress.  Or found another way.
>
> http://vhbit.net/blog/2014/04/12/rust-on-ios/

The blog post says that Rust has built-in TLS emulation. It seems it wasn't necessary to use a patched LLVM. Although, I have no idea which way was used in the end.

> Reports good progress beginning of this year too.
>
> http://vhbit.net/blog/2015/01/18/rust-for-ios-status-update/
>
> I've lately been work on unwinding SjLj exception in Fibers, because
> until the 2.067, there weren't any unittests to show it off.  It was
> funny seeing an exception thrown in one Fiber being caught by another
> Fiber! Luckily I've got that solved now.

Ok, I see.

-- 
/Jacob Carlborg

On Wednesday, 3 June 2015 at 04:53:05 UTC, ketmar wrote:
> On Wed, 03 Jun 2015 03:27:35 +0000, weaselcat wrote:
>
>> On Wednesday, 3 June 2015 at 03:15:32 UTC, Jonathan M Davis wrote:
>>> On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote:
>>>> so is std.xml the exception? How many other parts of the standard
>>>> library are like that?
>>>
>>> A few, but not many. Mostly, it's stuff that was done for D1 or very
>>> early D2 which hasn't been removed or replaced yet. std.xml, std.json,
>>> and std.stream are what come to mind. There may be a few others, but
>>> most of the stuff in Phobos is more recent and is properly maintained.
>>> Mostly, it's a question of what hasn't been added to the standard
>>> library yet rather than what needs to be replaced.
>>>
>>> - Jonathan M Davis
>> 
>> std.signals
>
> and there is an excellect replacement[1]!
>
> [1] https://github.com/phobos-x/phobosx/blob/master/source/phobosx/
> signal.d

Nice! just what I've been looking for. I hope it works as expected.

On Wed, 03 Jun 2015 14:38:12 +0000, Jonas Drewsen wrote:

>>> std.signals
>>
>> and there is an excellect replacement[1]!
>>
>> [1] https://github.com/phobos-x/phobosx/blob/master/source/phobosx/ signal.d
> 
> Nice! just what I've been looking for. I hope it works as expected.

i'm using it for several monthes now and found zero problems with it. it really works exactly like it's documentation says. ;-)

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
> I've been using D in all my personal projects for years now, but I
> lament coding C at work every day, and I pine for salvation.

I'm pretty lucky, I work at a small startup that does drones for agriculture and have had the freedom to pick whatever language I think is best for the tasks at hand. As such, we now have some image analysis software in the works that is 100% D (save for the C libraries it uses and a bit of shell script). That said though, it sounds like we're getting ENVI cheap, and I have an opportunity to take a training course on extending it with "IDL," so that might end up being a better fit for the project in the long run.

The other major project I've worked on there is a web app which I did in JS as there's hardly any choice in that domain.

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
> [...]

I work in an academic setting, so there's alot of freedom.  About the only thing really holding me back is that the local sys-admins can't:

  $ yum install gcd

on CentOS 7.  If D compilers were available in the standard software distribution channels for RedHat based Linux systems, D would be considered mainline enough for our use.

On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote:
> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>> [...]
>
> I work in an academic setting, so there's alot of freedom.  About the only thing really holding me back is that the local sys-admins can't:
>
>   $ yum install gcd
>
> on CentOS 7.  If D compilers were available in the standard software distribution channels for RedHat based Linux systems, D would be considered mainline enough for our use.

Can you install to $HOME ?

bye,
lobo

On Thursday, 18 June 2015 at 10:17:49 UTC, lobo wrote:
> On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote:
>> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>>> [...]
>> About the only thing really holding me back is that the local sys-admins can't:
>>
>>   $ yum install gcd
>>
>
> Can you install to $HOME ?

I can do that, but there are other developers in our group.  We need to be able to build each other's software.  Java, Python and C are accepted as standard languages around here and seem to cover all our needs.  Since we have a "complete set" adding a new one would be met with resistance.  Having command line tools available through standard software distribution channels would soften this resistance.

On Thursday, 18 June 2015 at 16:04:05 UTC, Chris Piker wrote:
> On Thursday, 18 June 2015 at 10:17:49 UTC, lobo wrote:
>> On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote:
>>> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>>>> [...]
>>> About the only thing really holding me back is that the local sys-admins can't:
>>>
>>>   $ yum install gcd
>>>
>>
>> Can you install to $HOME ?
>
> I can do that, but there are other developers in our group.  We need to be able to build each other's software.  Java, Python and C are accepted as standard languages around here and seem to cover all our needs.  Since we have a "complete set" adding a new one would be met with resistance.  Having command line tools available through standard software distribution channels would soften this resistance.

yum install ldc
?

On Thursday, 18 June 2015 at 16:04:05 UTC, Chris Piker wrote:
> On Thursday, 18 June 2015 at 10:17:49 UTC, lobo wrote:
>> On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote:
>>> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>>>> [...]
>>> About the only thing really holding me back is that the local sys-admins can't:
>>>
>>>   $ yum install gcd
>>>
>>
>> Can you install to $HOME ?
>
> I can do that, but there are other developers in our group.  We need to be able to build each other's software.  Java, Python and C are accepted as standard languages around here and seem to cover all our needs.  Since we have a "complete set" adding a new one would be met with resistance.  Having command line tools available through standard software distribution channels would soften this resistance.

If DMD is sufficient, I'm not really any problems.  Even FHS has your back.  Sysadmin does this:

cd /opt;
wget http://downloads.dlang.org/releases/2.x/2.067.1/dmd.2.067.1.linux.zip -qO tmp.zip \
&& unzip tmp.zip \
&& rm tmp.zip \
&& echo 'export PATH="${PATH}:/opt/dmd2/linux/bin64"' >> /etc/profile

...and voila.  It might be kind of nice to have a "latest" symlink for the download (e.g. http://downloads.dlang.org/releases/latest/dmd.latest.zip), but that'd just be icing.

Alternatively, ask have them make you a group-writable volume to use as a --prefix for everything that you might want (we ended up doing this because CantOS so strongly resembles LFS when you want to accomplish anything useful).  Or have people add ~cpiker/bin (or whatever your HOME is) to their PATH in ~/.profile (or just add the path in your Makefiles, if you're feeling evil).

It could certainly be better, but I wouldn't personally consider it a blocker as things are.

-Wyatt

On Thursday, 18 June 2015 at 16:10:09 UTC, rsw0x wrote:
>>>> About the only thing really holding me back is that the local sys-admins can't:
>>>>
>>>>   $ yum install gcd
>>>>
> yum install ldc

Interesting.  With the centos, epel, and rpmforge repositories
enabled:

$ yum search ldc

gives nothing.  Looks like only the fedora folks have this one.
Plus, what problems would you have linking against code that
was compiled with gcc?
--
Chris