Phil, since you're hacking on the VM, you need to rebase any pending
changes on the new_gc branch. In the last few days in particular I
rewrote a lot of code completely and moved many things around (some
not GC-related) so there's a chance your code might need changes. I
plan on doing some even mor
Hi Ed,
The problem in the compiler is that it invokes hashcode on literals. I
plan on fixing this soon.
The fact that 'foo new' doesn't give you a valid struct is itself not
a bug, though. You need to use .
Slava
On Mon, Oct 26, 2009 at 9:33 PM, Ed Swartz wrote:
> Hi,
>
> I get a segfault load
Hi,
I get a segfault loading this module (simplified), Linux-x86-32 from
master (stack trace below).
I looked a bit further and it seems that I should have been using
"" here, not "new". When I change that, the segfault goes away.
FWIW, "meshData new" works from the listener.
--
USING:
On Mon, Oct 26, 2009 at 6:37 PM, Hugh Aguilar wrote:
> It is unclear why Slava's Factor program is slower than mine, but I suspect
> that the DIP in HOW-FAR is the culprit.
Actually [ ... ] dip compiles to the same thing as >r ... r> in Forth.
It was faster than your version on x86-64 at least. I
There was a bug in the 32-bit compiler that was preventing Slava's LC53 from
running, but that has been fixed in the latest release. Here are the times:
Factor (Slava's)-- 11 minutes 14 seconds
http://paste.factorcode.org/paste?id=998
Factor (mine) - 9 minutes 14 seconds www.rosycrew.org/LC
2009/10/25 Phil Dawes :
> I like the on-demand idea but unfortunately at the moment all we have is
> the ability to pass startup args to the new vm. So vm A creates vm B and
> gets to pass some (command line) args to it, there's no mechanism where
> A can ask for a new pipe handle from B.
Hmm, no
Joe Groff wrote:
> On Sun, Oct 25, 2009 at 3:19 PM, Phil Dawes wrote:
>> I like the on-demand idea but unfortunately at the moment all we have is
>> the ability to pass startup args to the new vm. So vm A creates vm B and
>> gets to pass some (command line) args to it, there's no mechanism where
>
On Mon, Oct 26, 2009 at 8:37 PM, Bruce & Breeanna Rennie
wrote:
> Factor already has the ability to communicate with another server
> remotely using TCP/IP.
There's a concurrency.distributed vocab allowing sending messages
between VM's (uses sockets). Also a channels.remote which is currently
br
Phil,
Factor already has the ability to communicate with another server
remotely using TCP/IP. Why not use this to initiate communication with a
native VM thread and negotiate to use a fd descriptor as the
communication method afterwards hence bypassing TCP/IP. This way you can
come up with a
