View mode: basic / threaded / horizontal-split · Log in · Help
July 28, 2012
Re: Impressed
On 7/28/12 10:13 AM, Philippe Sigaud wrote:
> "bearophile" <bearophileHUGS@lycos.com <mailto:bearophileHUGS@lycos.com>>
>  > Gotos are not so evil. Just use them when they are useful and they
> can't be replaced by structured programming. In D I create finite state
> machines at compile-time that use gotos, they are quick.
>
> Do you happen to still have the code, by any chance? I think Phobos
> could use a std.fsm, to automatically generate FSM at compile-time
> (using lots of gotos :) ).

I've always found it difficult to generate FSMs from textual specs (as 
opposed to regexen or pretty images). Problem is you need to name your 
states, and in many FSMs intermediate states are not meaningful.

Andrei
July 28, 2012
Re: Impressed
On Friday, 27 July 2012 at 00:57:15 UTC, bearophile wrote:
> Stuart:
>
>> Why does D have GOTO? I haven't used GOTO in over a decade, 
>> because it's truly evil.
>
> Gotos are not so evil. Just use them when they are useful and 
> they can't be replaced by structured programming. In D I create 
> finite state machines at compile-time that use gotos, they are 
> quick.

Do FSMs really need to be spaghetti monsters? I heard, gcc 
optimizer can tear functions into common pieces and them 
reassemble the functions back from these pieces, or simply inline 
them, won't you get the same result?
July 28, 2012
Re: Impressed
On Saturday, 28 July 2012 at 16:07:14 UTC, Andrei Alexandrescu 
wrote:
> On 7/28/12 10:04 AM, Paulo Pinto wrote:
>> On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
>>> On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
>>>>
>>>> I tend to favour F# instead of OCaml due to three things
>>>
>>> I've never really seen the point of F#. Aside from maths, 
>>> what is F#
>>> good for that a standard imperative language is not? 
>>> Especially when
>>> you consider that all flavours of .NET have native support 
>>> for LINQ.
>>
>> Let me see:
>>
>> - Symbolic code manipulation;
>> - Metaprogramming;
>> - Easy parallelization of code thanks to immutable data 
>> structures and
>> workflows
>> - Type providers (comming in F# 3.0) to manipulate remote data 
>> as
>> language data types
>> - The right way of doing type inference (shared by all ML 
>> languages)
>> - Asynchronous programming builtin without having to wait for 
>> ..NET 4.5
>> - Algebraic data types
>>
>> Microsoft wouldn't have brought F# into Visual Studio if it 
>> wasn't worth
>> it, Microsoft is a business, not a language charity company.
>
> It was for Basic :o). Anyhow, indeed, the tools around it make 
> F# pretty cool (just not all that original as a language).
>
> Andrei

Sure, as I said it is all about having Microsoft's weight on it.
July 28, 2012
Re: Impressed
On Saturday, 28 July 2012 at 16:55:32 UTC, Kagamin wrote:
> On Friday, 27 July 2012 at 00:57:15 UTC, bearophile wrote:
>> Stuart:
>>
>>> Why does D have GOTO? I haven't used GOTO in over a decade, 
>>> because it's truly evil.
>>
>> Gotos are not so evil. Just use them when they are useful and 
>> they can't be replaced by structured programming. In D I 
>> create finite state machines at compile-time that use gotos, 
>> they are quick.
>
> Do FSMs really need to be spaghetti monsters? I heard, gcc 
> optimizer can tear functions into common pieces and them 
> reassemble the functions back from these pieces, or simply 
> inline them, won't you get the same result?

State machines encoded with goto tend not to be more spaghetti 
than their
specifications (say in regex or graph picture
July 28, 2012
Re: Impressed
Philippe Sigaud:

> Do you happen to still have the code, by any chance? I think 
> Phobos
> could use a std.fsm

The code is not general enough for Phobos.


Kagamin:

> I heard, gcc optimizer can tear functions into common pieces 
> and them reassemble the functions back from these pieces, or 
> simply inline them, won't you get the same result?

Sometimes those FSM are the only part of those small C or D 
programs where I don't trust the optimizers. But thankfully in 
C-GCC using a little of __builtin_expect() it's not necessary to 
generate the assembly directly from the FSM description.

Bye,
beaophile
July 28, 2012
Re: Impressed
> I'd say this argument on which is "better", yield or ranges, is 
> a problem ill posed.

Yeah, since yielding is just a convenient way to implement an 
input range, asking which is better is like asking "Which is 
better, pick-up trucks or vehicles?"

> "yield" adds real, nontrivial value, and is not entirely 
> implementable as a library. Walter and I saw some uses of it in 
> C# at Lang.NEXT that were quite impressive.
>
> On the other hand yield's charter is limited when compared to 
> that of ranges. Yield goes with the very simple "go through 
> everything once" functionality, which is essentially input 
> ranges - only a tiny part of ranges can do.

> "yield" adds real, nontrivial value, and is not entirely 
> implementable as a library. Walter and I saw some uses of it in 
> C# at Lang.NEXT that were quite impressive.

Agreed. However, I have been looking at D's Fibers and I wonder 
if an optimized implementation of them could provide the same 
functionality reasonably well:

https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

The only problem is performance (and perhaps memory usage, but 
there are ways to reduce that). Someone reported that a trivial 
fiber-based forward range had 26x the overhead of opApply for 
iteration (70s vs 2.7s for 1 billion iterations). I wonder if the 
fiber-switching could be optimized? But I looked at core/thread.d 
and unless I'm missing something, the fiber switch does not 
appear to do much work: it calls Thread.getThis() twice per 
switch (= 4 times per iteration), getStackTop() (= rt_stackTop) 
once, and a naked asm routine with 21 asm instructions. The 
entire yield() process contains no branches; call() additionally 
calls setThis() twice and checks if the Fiber threw an exception. 
What's the easiest way to time something in D? I'm curious if 
Thread.getThis() (= TlsGetValue()) is the bottleneck.

Anyway, stack-switching lets you do not only the same things as 
C# 2's "yield return" but as far as I can tell, it can also do 
everything that C# 5's "async/await" can do and more:

http://qscribble.blogspot.ca/2012/07/asyncawait-vs-stack-switching.html

i.e. stack switching can accomplish tasks that async/await 
cannot, while I don't know of any cases of the reverse. async is 
more limited because all functions involved in an async task must 
be explicitly marked and transformed by the compiler, but stack 
switching works no matter what code is involved; even C code can 
be called on an asynchronous fiber task.
July 28, 2012
Re: Impressed
On Saturday, 28 July 2012 at 08:05:09 UTC, Daniel Murphy wrote:
> "Stuart" <stugol@gmx.com> wrote in message
> news:vjaspnvbihpgvxgqmccr@forum.dlang.org...
>> Embedded systems mostly use Java now in any case, as I 
>> understand it.
>
> Your understanding is obviously quite limited.

 I've used the java compiler for GNU's compilers; Doesn't it 
compile to native code? In which case java in the right 
compiler/setup is the same as C/C++ (To a degree... with the 
appropriate runtime)
July 29, 2012
Re: Impressed
On Sat, 28 Jul 2012 20:32:57 +0200
"David Piepgrass" <qwertie256@gmail.com> wrote:

> What's the easiest way to time something in D?

{
   import std.datetime;
   StopWatch stopWatch;
   stopWatch.start();
   scope(exit)
       writeln(stopWatch.peek.msecs, "ms");
		
   // Do stuff to be timed
}


Or use my verboseSection wrapper:

https://bitbucket.org/Abscissa/semitwistdtools/src/8123e04b593c/src/semitwist/util/mixins.d#cl-644

bool verbose = true;
...
{
   mixin(verboseSection!"Making the fizzbar");
   makeFizzbar();
}
Output:
Making the fizzbar...732ms
July 29, 2012
Re: Impressed
On Sat, 28 Jul 2012 16:33:02 +0200
"Paulo Pinto" <pjmlp@progtools.org> wrote:

> On Saturday, 28 July 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
> >
> > God I hope that's not true. Using a VM on a low-power system is 
> > just so
> > rediculously *wrong* it should be a crime.
> 
> Java != VM
> 

Yea, people keep telling me that and I still keep forgetting :P
"Java==VM" has been ingrained pretty deeply into my brain for about 10
years. Hard to change that :)

Still, unless there's something different about these offerings, Java
(the langauge) has no low-level ability whatsoever, no manual
memory management and strongly encourages over-use of objects and heap
allocation. Even natively-compiled, that doesn't sound like my idea of a
good embedded language. But I dunno, I guess maybe if they're
using it in the sort of way that game devs use Lua...(Not that I'm a fan
of Lua - far too dynamic for my tastes.)
July 29, 2012
Re: Impressed
On Sunday, 29 July 2012 at 02:40:44 UTC, Nick Sabalausky wrote:

> Still, unless there's something different about these 
> offerings, Java (the langauge) has no low-level ability 
> whatsoever, no manual memory management and strongly encourages 
> over-use of objects and heap allocation. Even 
> natively-compiled, that doesn't sound like my idea of a good 
> embedded language. But I dunno, I guess maybe if they're using 
> it in the sort of way that game devs use Lua...(Not that I'm a 
> fan of Lua - far too dynamic for my tastes.)

 It does do low-level bit manipulation for built-in types, 
however I think that's it's limit.
12 13 14 15 16 17 18 19
Top | Discussion index | About this forum | D home