audio hijack

Just a reminder note (more for myself at this point): on OS X, the fine app Audio Hijack Pro has an extension
called Instant Hijack that causes emu's wm to lock up.  It's just the thread that where winproc() starts up
RunApplicationEventLoop() that causes the problem, aka: wm/wm& at least lets you do a few things on the console.

One of these days when I've got more time I'll get back to this issue and hopefully resolve it--and possibly
add audio support as well.  Until then, just uninstall Instant Hijack and all is good.

-jas

Re: audio hijack

Have you tried dtruss both processes to see where they hang?

On Wed, Jul 7, 2010 at 6:08 PM, Jeff Sickel <jas@...> wrote:
> Just a reminder note (more for myself at this point): on OS X, the fine app Audio Hijack Pro has an extension
called Instant Hijack that causes emu's wm to lock up.  It's just the thread that where winproc() starts
up RunApplicationEventLoop() that causes the problem, aka: wm/wm& at least lets you do a few things on the console.
>
> One of these days when I've got more time I'll get back to this issue and hopefully resolve it--and possibly
add audio support as well.  Until then, just uninstall Instant Hijack and all is good.
>
> -jas
>
>

Re: audio hijack

On Wed, Jul 7, 2010 at 2:17 PM, Noah Evans <noah.evans <at> gmail.com> wrote:

Have you tried dtruss both processes to see where they hang?

I can tell you that I've had to run emu as root with Audio Hijack Pro enabled in order to get it to work, and this was years ago.

Perhaps Audio Hijack Pro hijacks more than just audio?  

Dave

 

On Wed, Jul 7, 2010 at 6:08 PM, Jeff Sickel <jas-a3whXZxc5vT6UrM9D2HV8UEOCMrvLtNR@public.gmane.org> wrote:
> Just a reminder note (more for myself at this point): on OS X, the fine app Audio Hijack Pro has an extension called Instant Hijack that causes emu's wm to lock up.  It's just the thread that where winproc() starts up RunApplicationEventLoop() that causes the problem, aka: wm/wm& at least lets you do a few things on the console.
>
> One of these days when I've got more time I'll get back to this issue and hopefully resolve it--and possibly add audio support as well.  Until then, just uninstall Instant Hijack and all is good.
>
> -jas
>
>

Re: linux emu and XIO fatal errors

Upgraded to Ubuntu 10.x and so far have not been able to reproduce the error.  I'm not saying it is fixed, just
that I still need to do more testing to make sure that nothing needs to be fixed in emu.

Though in my testing, emu -s has been causing gdb to behave worse than I remember.  Again, too many variables
as of yet, I must trim them down before anything solid is available as a good contribution back.

-jas

On Jun 18, 2010, at 2:35 PM, Charles Forsyth wrote:

> if you can reliably reproduce it, and there's a way of converting the diagnostic into an abort + core dump,
> giving a stack trace, that might finally help to work out what causes it.

snarf device bug?

#^ (the snarf buffer device) is bound to two places, but serves a  
different function in each.

On /dev it communicates with the host clipboard, as snarf(3)  
describes. It works both ways quite happily, but does not communicate  
with tk.

On /chan it communicates with Tk or wm, but not with the host. The  
result is 2 separate clipboards, which is not desired behaviour.

% ns | grep '#\^'
bind -b '#^' /dev
bind -b '#^' /chan
% cat /dev/snarf
Dulux™ Color Matches%
% cat /chan/snarf
charon%

How do I fix it? `bind -b /dev/snarf /chan/snarf` gives an error:
bind: cannot bind /dev/snarf onto /chan/snarf: inconsistent mount

Re: snarf device bug?

On 14 July 2010 17:25, Ethan Grammatikidis <eekee57@...> wrote:
> How do I fix it? `bind -b /dev/snarf /chan/snarf` gives an error:
> bind: cannot bind /dev/snarf onto /chan/snarf: inconsistent mount

in /lib/wmsetup, you can add a line:

bind /dev/snarf /chan/snarf

i can't remember if this is the *right* way of doing it,
but it works on my machine at least.

Re: snarf device bug?

On 14 Jul 2010, at 18:39, roger peppe wrote:

> On 14 July 2010 17:25, Ethan Grammatikidis <eekee57@...>  
> wrote:
>> How do I fix it? `bind -b /dev/snarf /chan/snarf` gives an error:
>> bind: cannot bind /dev/snarf onto /chan/snarf: inconsistent mount
>
> in /lib/wmsetup, you can add a line:
>
> bind /dev/snarf /chan/snarf
>
> i can't remember if this is the *right* way of doing it,
> but it works on my machine at least.

Works on mine too. Cheers!

Re: snarf device bug?

>(the snarf buffer device) is bound to two places, but serves a  
>different function in each.
> on /dev ...
>On /chan it communicates with Tk or wm, but not with the host. The  
>result is 2 separate clipboards, which is not desired behaviour.

#^ isn't able to make two clipboards: it only ever reads and writes the host's
clipboard. the snarf files come from two distinct sources.

in your example:

	% ns | grep '#\^'
	bind -b '#^' /dev
	bind -b '#^' /chan

	% cat /dev/snarf
	Dulux™ Color Matches%

	% cat /chan/snarf
	charon%

you've only looked for #^ in the output of ns, but that doesn't tell you what's
uppermost on either /dev or /chan. almost certainly (as in my case), /dev has #^
topmost, but in /chan it's a completely different snarf file, served by wm/toolbar.

how to tell? ls -l is probably easiest:

% ls -l '#^'
--rw-rw-rw- ^ 0 forsyth forsyth 0 Mar 22 06:24 #^/snarf
% ls -l /dev/snarf
--rw-rw-rw- ^ 0 forsyth forsyth 0 Mar 22 06:24 /dev/snarf
% ls -l /chan/snarf
--rw-rw---- s 0 forsyth forsyth 0 Mar 22 06:24 /chan/snarf

and you'd have seen something similar in your case. the reason is that wm/toolbar puts #s
in a union mount on TOP of the #^ previously bound to /chan, and creates its own "snarf"
service there (using file2chan). wmsetup is presumably run after it does that, so adding
the bind -b to wmsetup means that the host-oriented snarf file overrides wm/toolbar's,
and is subsequently used by everything.

arguably wm/toolbar could check to see if a snarf file already exists, and not
create its own. that would make it harder to have separate clipboards, without an option,
but i expect most people find a single one more convenient, reducing the barriers between
applications.

Styx on a Brick Tarball Hunt

Hello,

I am trying to locate the legostyx.tar file that is mentioned here: 
http://www.vitanuova.com/inferno/rcx_paper.html
I scanned the links on that page and came up empty handed.  I'd like to 
try and write a styx-on-an-atmega (unless of course, someone already has 
:)).  I'm still a naive enough programmer that I absolutely need to do 
things by example, else it just won't happen.

Thanks,

Jack

Re: Styx on a Brick Tarball Hunt

On Fri, 16 Jul 2010 08:05:15 -0500
Jack Norton <jack@...> wrote:

> Hello,
> 
> I am trying to locate the legostyx.tar file that is mentioned here: 
> http://www.vitanuova.com/inferno/rcx_paper.html
> I scanned the links on that page and came up empty handed.  I'd like to 
> try and write a styx-on-an-atmega (unless of course, someone already has 
> :)).  I'm still a naive enough programmer that I absolutely need to do 
> things by example, else it just won't happen.

I can't find the tarball, but I think all of the files it contained are
in the Inferno distribution:

$ locate lego |grep -e 'inferno/[^.]'

Robert Ransom