acme-sac on windows is my development environment too.
b2 on 'win os cmd' gives a cmd.exe window. i prefer sh(1),
so i use just 'win' and access the windows files from /n/C.
i have shell functions defined in $home/lib/functions to
invoke specific windows commands.
for example:
fn ant {
> term% 8.out -c /bin/echo Boo!
> 511 echo Brk 0x3233 b450 = 0 "" 0x11af077310cde470
> 0x11af077310d0da40
> 511 echo Pwrite 0x31d6 1 a458/"Boo!." 5 -0x1Boo!
> = 5 "" 0x11af07731e11e758 0x11af077326aed448
> 511 echo Open 0x32c0 9ec0/"#c/pid" = 3 "" 0x11af0773
On Tue, 18 May 2010 18:54:21 PDT David Leimbach wrote:
>
> Were all of the binaries within recompiled against this code? Running 9vx
> on my iMac is pretty smooth!
vx32/src/9vx.*.gz are the same as before (in case you are running those).
Compiling 9vx on a MAC OS 10.6.3 required changing HOST
On Tue, May 18, 2010 at 9:52 PM, ron minnich wrote:
> On Wed, May 19, 2010 at 4:37 AM, David Leimbach wrote:
>
> > There were pre-built binaries in this cloned repo, I'm totally unable to
> > rebuild the Mac OS X binary, due to some "impossible constraint" in some
> > assembly or something like
On Wed, May 19, 2010 at 4:37 AM, David Leimbach wrote:
> There were pre-built binaries in this cloned repo, I'm totally unable to
> rebuild the Mac OS X binary, due to some "impossible constraint" in some
> assembly or something like that per my recollection. I was merely wondering
> if you expe
On Tue, May 18, 2010 at 7:13 PM, ron minnich wrote:
> On Wed, May 19, 2010 at 1:54 AM, David Leimbach wrote:
>
> > Were all of the binaries within recompiled against this code? Running
> 9vx
> > on my iMac is pretty smooth!
>
> Hm, not sure what you mean.
>
> ron
>
> There were pre-built binari
On Wed, May 19, 2010 at 1:54 AM, David Leimbach wrote:
> Were all of the binaries within recompiled against this code? Running 9vx
> on my iMac is pretty smooth!
Hm, not sure what you mean.
ron
> Were all of the binaries within recompiled against this code? Running 9vx
> on my iMac is pretty smooth!
trace device doesn't require user land support.
- erik
On Tue, May 18, 2010 at 5:22 PM, ron minnich wrote:
> http://bitbucket.org/rminnich/vx32
>
> this is my hack of vx32.
>
Were all of the binaries within recompiled against this code? Running 9vx
on my iMac is pretty smooth!
Dave
>
> It includes a ram block device, but more importantly, it sup
On Tue, 18 May 2010 20:40:15 -0400
Jorden M wrote:
> On Tue, May 18, 2010 at 7:59 PM, ron minnich wrote:
> > On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento
> > wrote:
> >> just a comment, the python port includes some hg bits because of my
> >> lazyness
> >> the thing is that hg isn't
On Tue, May 18, 2010 at 7:59 PM, ron minnich wrote:
> On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento
> wrote:
>> just a comment, the python port includes some hg bits because of my lazyness
>> the thing is that hg isn't just python, it has some c modules that had
>> to be built
>> in in p
http://bitbucket.org/rminnich/vx32
this is my hack of vx32.
It includes a ram block device, but more importantly, it supports the
system call trace code.
In the 'root' of the repo is the syscalltrace directory; cd in there
to make the syscalltrace binary.
Comments and improvements welcome. Noah
On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento
wrote:
> just a comment, the python port includes some hg bits because of my lazyness
> the thing is that hg isn't just python, it has some c modules that had
> to be built
> in in python, so python needs to be recompiled to support hg...
> so
just a comment, the python port includes some hg bits because of my lazyness
the thing is that hg isn't just python, it has some c modules that had
to be built
in in python, so python needs to be recompiled to support hg...
so I went the easy way, python already comes with the hg c code.
On Mon, M
> It seems like windows console
> programs work with screen buffers, something like using curses.
This is the case for a few windows commands but many, even the majority don't
use windows console functions, they just read from stdin and writ to stdout
so you can run then via a pipe.
I do this all
On Tue, May 18, 2010 at 2:35 PM, Georg Lehner wrote:
> Another view on software managment:
>
> http://cr.yp.to/slashpackage/management.html
My system is very close to that.
But I still like the idea that you have as little state as possible,
and that package installation be so convenient you do
On Tue, May 18, 2010 at 11:42 PM, Ethan Grammatikidis
wrote:
>
> if cmd.exe behaves itself you'd have an
> acme window with cmd.exe in it.
>
I think it does not behave itself. I think Windows consoles don't work
like UNIX /dev/pty*, but like /dev/vcs*. It seems like windows console
programs work
Another view on software managment:
http://cr.yp.to/slashpackage/management.html
Regards,
Jorge-León
On 2010-05-16 20:58, Corey wrote:
On Sunday 16 May 2010 10:34:53 EBo wrote:
Have you tried Sorcery from Source Mage?
No, but I'll definitely look into it. Thanks for the poi
On 18 May 2010, at 21:24, Aram Hăvărneanu wrote:
Hello,
I've been a long time vi(m) user. I use it everywhere, UNIX or
Windows. I explored other alternatives and I am very happy with acme.
Acme is great.
(Unfortunately), I have to use Windows. I write Windows drivers. I use
acme-sac and runs
Hello,
I've been a long time vi(m) user. I use it everywhere, UNIX or
Windows. I explored other alternatives and I am very happy with acme.
Acme is great.
(Unfortunately), I have to use Windows. I write Windows drivers. I use
acme-sac and runs great on Windows. However, acme is more then an
edito
20 matches
Mail list logo
