To clarify: guile does not yet do cross module inlining. It was mentioned as a
potential thing in the thread about native guile SHA2(?) implementation. As
such there is nothing to learn about it. Potential heuristics and how to make
it clear to the optimizer what is simple re-exports I leave to
Hi,
Linus Björnstam wrote:
> I just re-read my message and noticed it could come off as somewhat
> dismissive.
> Ah, the joys of not having English as a first language while being a tired
> father :)
Didn't strike me particularly as such. So, all is good.
> I looked through your code. It is ni
Hi Chris!
On 1/8/20 12:44 PM, Chris Vine wrote:
> On Wed, 8 Jan 2020 08:56:11 +0100
> Zelphir Kaltstahl wrote:
> [snip]
>> So my questions are:
>>
>> - Is there a default / recommended way to limit parallelism for
>> recursive calls to parallel forms?
>>
>> - Is there a better way than a global c
Thanks for your suggestion, I will take it into account.
Regards,
Zelphir
On 1/8/20 9:11 AM, Linus Björnstam wrote:
> Hi!
>
> I don't have much more input than to say that futures use a built in thread
> pool that is limited to (current-processor-count) threads. That could maybe
> be modified
Hey again!
I just re-read my message and noticed it could come off as somewhat dismissive.
Ah, the joys of not having English as a first language while being a tired
father :)
I looked through your code. It is nicer than mine, but why did you chose to not
just re-export bindings that are avail
John Cowan wrote:
[...]
> The reason bitwise-nand and friends have only two arguments (and this comes
> from Olin's original) is that they aren't associative: it's ambiguous
> whether (bitwise-nand a b c) means (bitwise-nand (bitwise-nand a b) c) or
> (bitwise-nand a (bitwise-nand b c)), and these
On Thu, Jan 9, 2020 at 7:55 AM Frank Terbeck wrote:
Linus Björnstam wrote:
> > Your bitwise-nand etc takes more arguments than they have to. They are
> > 2-argument procedures according to the spec, which gives you better
> performance
> > than the apply-dance you are doing now. Maybe have a bitw
Linus Björnstam wrote:
> Your bitwise-nand etc takes more arguments than they have to. They are
> 2-argument procedures according to the spec, which gives you better
> performance
> than the apply-dance you are doing now. Maybe have a bitwise-nand and a
> bitwise-nand*?
Yeah, I did that on purpos
Your bitwise-nand etc takes more arguments than they have to. They are
2-argument procedures according to the spec, which gives you better performance
than the apply-dance you are doing now. Maybe have a bitwise-nand and a
bitwise-nand*?
--
Linus Björnstam
On Thu, 9 Jan 2020, at 10:10, Frank
Hi Linus!
Linus Björnstam wrote:
> I have a port of the SRFI code as well, using renaming of guile and srfi-60
> procedures as necessary.
I see! I did mine from scratch, while reading the spec.
> It has the make-bitwise-generator from srfi-151.
Interesting. I thought the generators were part
10 matches
Mail list logo
