gusi-discussion — Discussions of GUSI related questions and bugs.

Re: [GUSI] Mac port of SFIO requires GUSI?

[<mps...@hi...>]

On Sun, 23 Oct 2005 23:24:18 -0700
Matthias Neeracher <nee...@ma...> wrote:

>On Oct 23, 2005, at 10:44 PM, mps...@hi... wrote:
>> Just I managed to build GUSI by vanilla MPW. When I proceed to
>> Natty,
>
>Unfortunately, I don't think Natty ever evolved into useful code, as  
>I stopped using classical MacOS soon after I started that project.

Thank you very much about the point of matter.
I give it up to use Natty as exec() family for MPW.

Is there any recommended library to execute MPW command as exec()?
I'm looking for such, even if it's for Mac OS X. As I've written
before, I'm trying to port Jam (yet another "make" replacement)
to automake MPW building procedure.

Regards,
mpsuzuki

Re: [GUSI] Mac port of SFIO requires GUSI?

[Matthias N. <nee...@ma...>]

On Oct 23, 2005, at 10:44 PM, mps...@hi... wrote:
> Just I managed to build GUSI by vanilla MPW. When I proceed to
> Natty,

Unfortunately, I don't think Natty ever evolved into useful code, as  
I stopped using classical MacOS soon after I started that project.

> I found that Natty requires Sfio, I want to compile it
> by vanilla MPW. Although precompiled Sfio libraries are provided,
> but it's a bit difficult to understand how to install and use
> it to build GUSI_SFIO module (and Natty). But I could not understand
> how to rebuild Mr. Matthias Neeracher's MacOS port of Sfio by MPW.

I don't remember the details exactly anymore, but I'm fairly sure  
that Sfio cannot easily be ported to the MPW libraries.

> After buildings Sfio on UNIX system, I understood AT&T guys
> created "iffe" sh script instead of GNU autoconf, to generate
> system-dependent header files (e.g. FEATURE/sfio). Nothing
> to say, iffe cannot work in MPW Shell, it seems that Mr. Matthias
> Neeracher writes FEATURE/sfio manually

Yes, porting sh to MPW was a bit beyond my skills :-)

> (I could find FEATURE:sfio
> in package released on 1997, but I could not find it in the last
> package on 1999). It seems that the ported Sfio sources try to
> include non-MPW header files (e.g.: sys/types.h, sys/time.h by
> ast_common.h). Are they designed to include headers in GUSI
> (rather, BSD headers included in GUSI)?

Not only the headers, but also the libraries to go with them.

Matthias

[GUSI] Mac port of SFIO requires GUSI?

[<mps...@hi...>]

Dear Sirs,

Just I managed to build GUSI by vanilla MPW. When I proceed to
Natty, I found that Natty requires Sfio, I want to compile it
by vanilla MPW. Although precompiled Sfio libraries are provided,
but it's a bit difficult to understand how to install and use
it to build GUSI_SFIO module (and Natty). But I could not understand
how to rebuild Mr. Matthias Neeracher's MacOS port of Sfio by MPW.

After buildings Sfio on UNIX system, I understood AT&T guys
created "iffe" sh script instead of GNU autoconf, to generate
system-dependent header files (e.g. FEATURE/sfio). Nothing
to say, iffe cannot work in MPW Shell, it seems that Mr. Matthias
Neeracher writes FEATURE/sfio manually (I could find FEATURE:sfio
in package released on 1997, but I could not find it in the last
package on 1999). It seems that the ported Sfio sources try to
include non-MPW header files (e.g.: sys/types.h, sys/time.h by
ast_common.h). Are they designed to include headers in GUSI
(rather, BSD headers included in GUSI)?

Regards,
mpsuzuki

Re: [GUSI] How to build GUSI by MPW without CW?

[Joshua J. <jj...@gm...>]

On Oct 4, 2005, at 3:54 AM, mps...@hi... wrote:

> On Tue, 4 Oct 2005 02:44:37 -0400
> Joshua Juran <jj...@gm...> wrote:
>
>> On Oct 4, 2005, at 1:01 AM, mps...@hi... wrote:
>>
>>> Now I'm trying to port Jam (yet-another "make" whose syntax
>>> is sh + perl + make mixage) onto MPW. Nothing to say, I need
>>> execl() etc that native Mac Toolbox don't have. I want to use
>>> GUSI for library for such POSIX functions.
>>
>> A fundamental problem faces you -- MPW is crippled by design in that
>> only MPW Shell scripts can execute other programs -- compiled tools
>> (and consequently scripts interpreted by such tools) cannot.  This is
>> one of the reasons I stopped using MPW for my build environment 
>> (though
>> I still use ToolServer to run the compiler and linker).
>>
>> You might be interested in my Genie environment (which is open source
>> but way out-of-date on the Web), which I developed to replace MPW.
>
> Yes, of course. Working with MPW CLI makes me much frustrated,
> and I wish if I had UNIX shell-like CLI to run MPW compilers.
> Can I execute SC, MrC and linkers on Genie? I have to study
> about ToolServer?

ToolServer is basically MPW Shell with a minimal user interface, and I 
do mean minimal -- you can't edit documents, or even invoke commands.  
It has a little status window that shows what tool (if any) is running. 
  You interact with it by sending it a Do Script Apple event.

The context required to run an MPW tool is non-trivial and (to my 
knowledge) undocumented.  Genie is not able to host MPW tools directly 
and probably never will.  For open source tools such as grep, the 
solution is to build them for Genie.  For closed source, I wrote 
tlsrvr, a Genie program that encapsulates sending a Do Script event to 
ToolServer and capturing the output.  In the same way that a kernel 
recognizes a script as executable and spawns an interpreter for it, 
Genie considers MPW tools executable and runs them through tlsrvr, so 
you don't even need to mention it explicitly.

Josh

-- 
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

Re: [GUSI] How to build GUSI by MPW without CW?

[<mps...@hi...>]

Dear Mr. Joshua Juran,

On Tue, 4 Oct 2005 02:44:37 -0400
Joshua Juran <jj...@gm...> wrote:

> On Oct 4, 2005, at 1:01 AM, mps...@hi... wrote:
> 
> > Now I'm trying to port Jam (yet-another "make" whose syntax
> > is sh + perl + make mixage) onto MPW. Nothing to say, I need
> > execl() etc that native Mac Toolbox don't have. I want to use
> > GUSI for library for such POSIX functions.
> 
> A fundamental problem faces you -- MPW is crippled by design in that 
> only MPW Shell scripts can execute other programs -- compiled tools 
> (and consequently scripts interpreted by such tools) cannot.  This is 
> one of the reasons I stopped using MPW for my build environment (though 
> I still use ToolServer to run the compiler and linker).
> 
> GUSI doesn't have the exec() functions.

Oops, thank you very much for importang pointing-out!
When I take a glance on GUSI, its unistd.h includes
exec() family, but checking files a bit more carefully,
now I understand the header files come from BSD Unix,
they are not scratched for GUSI.

>                                          Matthias was working on a 
> package called Natty <http://sourceforge.net/projects/natty/>, which 
> did.  I haven't played with it at all, so I can't say much about it, 
> although I did steal a very good idea for implementing vfork().

Thank you, checking Natty has been stacked on my queue.

> You might be interested in my Genie environment (which is open source 
> but way out-of-date on the Web), which I developed to replace MPW.  

Yes, of course. Working with MPW CLI makes me much frustrated,
and I wish if I had UNIX shell-like CLI to run MPW compilers.
Can I execute SC, MrC and linkers on Genie? I have to study
about ToolServer?

Regards,
mpsuzuki

Re: [GUSI] How to build GUSI by MPW without CW?

[Joshua J. <jj...@gm...>]

On Oct 4, 2005, at 1:01 AM, mps...@hi... wrote:

> Now I'm trying to port Jam (yet-another "make" whose syntax
> is sh + perl + make mixage) onto MPW. Nothing to say, I need
> execl() etc that native Mac Toolbox don't have. I want to use
> GUSI for library for such POSIX functions.

A fundamental problem faces you -- MPW is crippled by design in that 
only MPW Shell scripts can execute other programs -- compiled tools 
(and consequently scripts interpreted by such tools) cannot.  This is 
one of the reasons I stopped using MPW for my build environment (though 
I still use ToolServer to run the compiler and linker).

GUSI doesn't have the exec() functions.  Matthias was working on a 
package called Natty <http://sourceforge.net/projects/natty/>, which 
did.  I haven't played with it at all, so I can't say much about it, 
although I did steal a very good idea for implementing vfork().

You might be interested in my Genie environment (which is open source 
but way out-of-date on the Web), which I developed to replace MPW.  
Genie is a Mac app that provides a unix-like kernel and command shell 
windows.  I borrowed and improved on Natty's vfork() implementation, so 
spawning other programs is no problem.  My port of perl has working 
system() and piped open(), and a toy httpd runs CGI shell or Perl 
scripts.

Genie is part of a larger project called Lamp (Lamp Ain't Mac POSIX) 
<http://sourceforge.net/projects/lamp/>.  I'm afraid you won't find on 
the site information more useful (and certainly not more current) than 
what I've just told you, and the CVS is out of date (since I use my own 
now), but I would be delighted to update it if you're interested, and 
I've been meaning to do so anyway.

> GUSI package is provided with precompiled libraries for MPW
> and CW, but I want to build library for MPW from source,
> because STLport is already updated. STLport-3.1.2 which
> GUSI-2.2.3 is noted as built with is unavailable.
> STLport-3.12.x might be similar, but I'm not sure about
> the compatilibity.

I'll add here that Genie uses C++ constructs that effectively require 
CodeWarrior (since MrCpp can't handle them).  But userland programs 
(e.g. jam) can be written in any language that can handle C bindings, 
and MrC should be usable, although I haven't tried it and my own build 
system doesn't support it.

> It seems that GUSI tarball includes makefiles with suffix
> ".mk" and ".nw". I suppose makefiles with ".mk" is for
> "dmake", but I could not find documents to compile by myself.
> How to build GUSI from source?

You're right about  '.mk', and '.nw' stands for either noweb or 
neitherweb.  It's a literate programming system.  You run the 'tangle' 
tool to get source code, and 'weave' to get formatted documentation.  
Or just look in the 'tangled' directory and use the source there.  I've 
never used it.

I hope that helps.

Josh

-- 
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

[GUSI] How to build GUSI by MPW without CW?

[<mps...@hi...>]

Dear Sirs,

Now I'm trying to port Jam (yet-another "make" whose syntax
is sh + perl + make mixage) onto MPW. Nothing to say, I need
execl() etc that native Mac Toolbox don't have. I want to use
GUSI for library for such POSIX functions.

GUSI package is provided with precompiled libraries for MPW
and CW, but I want to build library for MPW from source,
because STLport is already updated. STLport-3.1.2 which
GUSI-2.2.3 is noted as built with is unavailable.
STLport-3.12.x might be similar, but I'm not sure about
the compatilibity.

It seems that GUSI tarball includes makefiles with suffix
".mk" and ".nw". I suppose makefiles with ".mk" is for
"dmake", but I could not find documents to compile by myself.
How to build GUSI from source?

Regards,
mpsuzuki

Re: [GUSI] State of GUSI?

[Joshua J. <wan...@me...>]

On Nov 18, 2004, at 6:10 PM, Matthias Neeracher wrote:

> On Nov 16, 2004, at 1:56 AM, Joshua Juran wrote:
>>> I'd also be happy to turn over the Sourceforge project over to 
>>> anybody interested.
>>
>> I'm interested in and willing to contribute official support for 
>> Carbon and shared library deployment.  As maintainer, though, I would 
>> want to make some significant changes.
>
> That would definitely be your prerogative. My comments on the specific 
> issues your raise are meant to be purely advisory, the decision would 
> entirely be yours:
>
>> I found SIOUX difficult to work with.  I would integrate GUSI with 
>> Genie (my command shell app for OS 9) instead.  Programs with a 
>> command-line interface would be Genie plugins.
>
> That's an interesting idea. I think there would be value in supporting 
> both kinds of console interface (The console interface in GUSI is 
> somewhat modular, since it also has to support e.g. the MacPerl 
> console). People testing a one-shot program may not want to learn 
> Genie.

My objection is not general to all standalone console interfaces; 
rather that SIOUX had some default behavior I didn't care for (e.g. 
modal "Are you sure" dialog on quit) and I had difficulty correctly 
integrating it with GUSI when I ported TinyMUSH.  Of course, that was 
almost a decade ago.  My other thought is, why use a proprietary 
library when we can code something at least as good, if not better?

Double-clicking a Genie plugin or script causes Genie to run it (with 
no arguments), opening a new window if any console I/O occurs.  Genie's 
API is POSIX, as close as I can make it.  That's about what you'd 
expect from a standalone console app.  The current behavior resembles 
MacPerl droplets; if MacPerl-runtime-like deployment was desired, that 
would be possible too, either by grouping files together in a bundle 
(OS X) or package (OS 9), by installing a plugin fragment or script 
into a resource in the runtime, or by static linking the whole thing.

In the next few weeks, I'll put some serious work into Genie's Web 
page, so I'm not the only one who knows what I'm talking about.  :-)

>> I use templates rather than virtual methods where possible (i.e. for 
>> static dispatch)
>>
>> I prefer to use Nitrogen <http://sourceforge.net/projects/nitric/>, a 
>> C++ wrapper API for the Mac Toolbox.  This would rule out weak 
>> compilers like MrC.  CodeWarrior Pro 6 (the last version to support 
>> 68K development) is supported.
>
> I find that supporting a free set of development tools has 
> considerable advantages, but it certainly wouldn't be unprecedented to 
> go CW-only (which GUSI was a for several years in its existence).

GCC front-end compilers all compile to a platform-independent syntax 
tree.  All we have to do is port g++ to Genie (or any other POSIXish 
environment for Mac OS *smirk*), run a back-end 'compiler' that 
produces standard C, feed that into an MPW-provided compiler, and Bob's 
your uncle. :-)

I just checked:  LLVM may do the trick of compiling C++ into C.

  The LLVM Compiler Infrastructure Project
<http://llvm.cs.uiuc.edu/>

>> I wonder if it makes sense to start a new project GUSI3.
>
> Yes. That's one of the points on which I have a somewhat stronger 
> opinion: I'd prefer that you substantially bump the version number if 
> the code changes in ways as significant as what you're discussing 
> here.

GUSI Aleph Null?  :-)

Josh

-- 
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

Re: [GUSI] State of GUSI?

[Matthias N. <nee...@ma...>]

On Nov 16, 2004, at 1:56 AM, Joshua Juran wrote:
>> I'd also be happy to turn over the Sourceforge project over to 
>> anybody interested.
>
> I'm interested in and willing to contribute official support for 
> Carbon and shared library deployment.  As maintainer, though, I would 
> want to make some significant changes.

That would definitely be your prerogative. My comments on the specific 
issues your raise are meant to be purely advisory, the decision would 
entirely be yours:

> I found SIOUX difficult to work with.  I would integrate GUSI with 
> Genie (my command shell app for OS 9) instead.  Programs with a 
> command-line interface would be Genie plugins.

That's an interesting idea. I think there would be value in supporting 
both kinds of console interface (The console interface in GUSI is 
somewhat modular, since it also has to support e.g. the MacPerl 
console). People testing a one-shot program may not want to learn 
Genie.

> Maybe I just haven't given it a chance, but I'm not fond of the 
> literate programming style.  I'm quite comfortable with straight 
> source, and it's one less tool to maintain.

Yes, I think the LP style was one of the barriers to accessibility for 
other programmers (although arguably, GUSI 2 is somewhat better 
commented than GUSI 1, which might be due to LP).

> I use templates rather than virtual methods where possible (i.e. for 
> static dispatch)
>
> I prefer to use Nitrogen <http://sourceforge.net/projects/nitric/>, a 
> C++ wrapper API for the Mac Toolbox.  This would rule out weak 
> compilers like MrC.  CodeWarrior Pro 6 (the last version to support 
> 68K development) is supported.

I find that supporting a free set of development tools has considerable 
advantages, but it certainly wouldn't be unprecedented to go CW-only 
(which GUSI was a for several years in its existence).

> I wonder if it makes sense to start a new project GUSI3.

Yes. That's one of the points on which I have a somewhat stronger 
opinion: I'd prefer that you substantially bump the version number if 
the code changes in ways as significant as what you're discussing here.

Matthias

Re: [GUSI] State of GUSI?

[Joshua J. <wan...@me...>]

On Nov 15, 2004, at 12:50 AM, Matthias Neeracher wrote:

> On Nov 14, 2004, at 8:35 PM, Joshua Juran wrote:
>> The list has been dormant for well over a year, and the CVS has been=20=

>> inactive for almost two.  Is this project dead, or just resting?
>
> An excellent question, and thanks for bringing it up!

Thanks for the quick response.

> For a variety of reasons, I never did any Carbon development =96=A0I=20=

> basically moved from Classic directly to Cocoa/BSD. I have no further=20=

> plans with GUSI, but I definitely wouldn't want to stand in the way of=20=

> anybody who wants to take the code forward in any way. The GUSI=20
> license should be liberal enough to permit pretty much any conceivable=20=

> use (Including printing out the source code onto heavy paper stock and=20=

> clubbing baby seals with it, although that would sadden me).

SourceForge lists the zlib/libpng license for GUSI.  I think it's even=20=

GPL-compatible.

> I'd also be happy to turn over the Sourceforge project over to anybody=20=

> interested.

I'm interested in and willing to contribute official support for Carbon=20=

and shared library deployment.  As maintainer, though, I would want to=20=

make some significant changes.

I found SIOUX difficult to work with.  I would integrate GUSI with=20
Genie (my command shell app for OS 9) instead.  Programs with a=20
command-line interface would be Genie plugins.

Maybe I just haven't given it a chance, but I'm not fond of the=20
literate programming style.  I'm quite comfortable with straight=20
source, and it's one less tool to maintain.

I use templates rather than virtual methods where possible (i.e. for=20
static dispatch)

I prefer to use Nitrogen <http://sourceforge.net/projects/nitric/>, a=20
C++ wrapper API for the Mac Toolbox.  This would rule out weak=20
compilers like MrC.  CodeWarrior Pro 6 (the last version to support 68K=20=

development) is supported.

I wonder if it makes sense to start a new project GUSI3.

Josh

--=20
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

Re: [GUSI] State of GUSI?

[Jack J. <Jac...@cw...>]

On 15 Nov 2004, at 06:50, Matthias Neeracher wrote:

>
> On Nov 14, 2004, at 8:35 PM, Joshua Juran wrote:
>> The list has been dormant for well over a year, and the CVS has been=20=

>> inactive for almost two.  Is this project dead, or just resting?
>
> An excellent question, and thanks for bringing it up!
>
> For a variety of reasons, I never did any Carbon development =96=A0I=20=

> basically moved from Classic directly to Cocoa/BSD.

Alexandre Parenteau did a Carbon port, with some help from me and a few=20=

other people. It's in the CVS repository as tag CARBON-BRANCH.

It's been used in MacPython for MacOS9 for years, so it should be=20
fairly stable (at least, in as far as Python exercises the parts).
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma=20
Goldman

Re: [GUSI] State of GUSI?

[Matthias N. <nee...@ma...>]

On Nov 14, 2004, at 8:35 PM, Joshua Juran wrote:
> The list has been dormant for well over a year, and the CVS has been=20=

> inactive for almost two.  Is this project dead, or just resting?

An excellent question, and thanks for bringing it up!

For a variety of reasons, I never did any Carbon development =96=A0I=20
basically moved from Classic directly to Cocoa/BSD. I have no further=20
plans with GUSI, but I definitely wouldn't want to stand in the way of=20=

anybody who wants to take the code forward in any way. The GUSI license=20=

should be liberal enough to permit pretty much any conceivable use=20
(Including printing out the source code onto heavy paper stock and=20
clubbing baby seals with it, although that would sadden me).

I'd also be happy to turn over the Sourceforge project over to anybody=20=

interested.

Matthias Neeracher

[GUSI] State of GUSI?

[Joshua J. <wan...@me...>]

Hello,

The list has been dormant for well over a year, and the CVS has been 
inactive for almost two.  Is this project dead, or just resting?

I've built GUSI as a shared library, and now I'm interested in Carbon 
support, using CFMLateImport to get native POSIX on Mac OS X.  I'm 
willing to contribute code, and I understand some of the work has 
already been done.

Who's interested?

Josh

-- 
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

[GUSI] Test -- please ignore

[Joshua J. <wan...@me...>]

-- 
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

[GUSI] non-blocking networking support

[Philip D. W. <pw...@ma...>]

Does GUSI actually support non-blocking networking (at least for TCP)?

I appear to be using a Carbonized version of GUSI 2.2.2, and it doesn't 
seem to actually non-block when I request it. I'm under the impression 
that Open Transport endpoints are blocking by default, and that you 
have to call OTSetNonBlocking to set the endpoint into non-blocking 
mode, even for async endpoints. I didn't find any instance of this call 
in the source. Setting the socket option for non-blocking just sets a 
flag in GUSI's data structure for a socket. So, er, am I missing 
something?

----------------------------------------
Philip D. Wasson
Senior Software Engineer
Managing Editor Inc.
pw...@ma...

[GUSI] GUSI Linker Error: global object already declared

[Sebastian S. <ssc...@ma...>]

Hello,

with GUSI 2.2.3 and CWPro 5.3. I have the following problem:

I have a socket program that compiles and runs successfully
as long as I make an executable. But now I want to compile the
functions into a library and link it to some other code.
Building the library works correctly. But when linking it to the
new code, I get linker errors:

  GUSIConfig.cp: Global Object 'GUSISetupConfig'
    was already declared in File:
       'the file created by GUSI config'

  GUSIDescriptor.cp: Global Object 'GUSISetupConsoleDescriptors'
    was already declared in File: 'GUSISIOUX.cp'

  GUSIDescriptor.cp: Global Object 'GUSIStdioClose'
    was already declared in File: 'GUSIMSL.cp'

  GUSIDescriptor.cp: Global Object 'GUSIStdioFlush'
    was already declared in File: 'GUSIMSL.cp'

  GUSIDescriptor.cp: Global Object 'GUSISetupConsoleStdio'
    was already declared in File: 'GUSIMSL.cp'

The project targets are 68K Std C++ Consoles.
The linker settings are the same when building the library and when
linking it to the new code. When building the library, I put the
file created by GUSI Config first and then GUSI_SIOUX.68K.Lib,
GUSI_MSL.68K.Lib, and GUSI_Core.68K.Lib

Is there a simple solution?
Thank you very much,         Sebastian

[GUSI] GUSI time returns Jan 1972?

[John C. <jo...@he...>]

Hi All:

We are using GUSI and we noticed that our date functions are getting 
the wrong data back.  We call now(), which ends up in GUSI's time 
routines and for a reason we can't figure out, it's returning Jan 1972. 
(The day part escapes me now...)

Any idea why this might be happening?

Thanks for your time


John Cebasek
jo...@he...

[GUSI] [Gusi Announcement] GUSI 2.2.3 released

[Matthias N. <nee...@ma...>]

GUSI 2.2.3 is now available for downloading from:

https://sourceforge.net/project/showfiles.php?group_id=7941

Due to the substantial changes in this release, I've held up announcing 
it for a few days while Chris Nandor tested it with MacPerl, but 
everything seems to work.

Version 2.2.3		18Nov02

  - Fix timescale in ualarm [Chris Nandor, GUSI Bug #442180].
  - Since _exit() in MacPerl takes delayed effect, we need to make sure 
not to execute SIG_DFL as
  	a procedure pointer [Chris Nandor, GUSI Bug #564063].
  - Reengineered signal handling to properly handle handlers that 
longjmp() [GUSI Bug #564063].
    Please also read the manual changes clarifying whatkind of signal 
handlers GUSI supports.
  - Fix bug that caused GUSI to skip the first entry in getservby... 
[GUSI Bug #548891]
  - Fix infinite recursion in rename of locked file [MacPerl Bug 
#561694].
  - MPW codepath falsely permitted files with noexistent parent 
directories [GUSI Bug #553817].



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Gusi-announce mailing list
Gus...@li...
https://lists.sourceforge.net/lists/listinfo/gusi-announce

[GUSI] Yield is really yielding?

[John C. <jo...@he...>]

Hi All:

We've got a bug where it appears that when we request data from a 
server, the first request goes into a wait and doesn't complete until a 
second request is made.

Reading the code, I discover:

  if (!GetFrontProcess(&front) && !SameProcess(&front, &fProcess, &same) 
&& same)
  	GUSIConfiguration::Instance()->CheckInterrupt();
	if (wait == kGUSIBlock) {
		fWillSleep = true;
		if (fReadyThreads > 1 || fDontSleep) {
			GUSI_SMESSAGE("Don't Sleep\n");
			wait = kGUSIYield;
		}
	}
	if (fExistingThreads < 2) // Single threaded process skips sleep only 
once
		fDontSleep = false;
	if (wait == kGUSIYield && LMGetTicks() - fResumeTicks < 
kProcessTimeSliceTicks) {
		fWillSleep 		= false;
		return;
	}
	if (gGUSISpinHook) {
		gGUSISpinHook(wait == kGUSIBlock);
	} else {
		GUSI_SMESSAGE("Suspend\n");
		GUSIHandleNextEvent(wait == kGUSIBlock ? kProcessSleepTicks : 0);
		GUSI_SMESSAGE("Resume\n");
	}
	if (fExistingThreads < 2) 		// Single threaded process skips sleep 
only once
		fDontSleep = false;
	fWillSleep 		= false;
	fResumeTicks 	= LMGetTicks();
	if (fClosing)
		fClosing->CheckClose();
}


According to Metrowerks debugger, the pc is in the if 
(!GetFrontProcess()...) line. Also, this is happening on a 
multiprocessor macintosh.

Any ideas as to why this wait might be happening? What are the issues 
for MP macs and GUSI. What about using CW 7 built libraries with CW8?  
(GUSI using headers that appear to have been deprecated.)

And the line GUSIConfiguration::Instance()->CheckInterrupt(), are we 
missing a set of curly brackets?


Any ideas would be appreciated.


John Cebasek
jo...@he...

Re: [GUSI] MIT Support Library

[Keith R. <kei...@pa...>]

At 2:39 PM -0500 11/23/02, Simon Lemieux wrote:
>-Sam:
>
>>  If anybody else (like me) can't get GUSI to work they might be interested
>>  in the MIT support library for clients.
>
>And where can we find some information about this MIT support library?

I'm continually amazed at the number of people who aren't familiar 
with search engines, and Google in particular, especially among the 
programming community.  If you go to <http://www.google.com>, you can 
type or paste in a phrase, and that Web site will return to you a 
list of other Web sites that contain that phrase.  By entering "MIT 
support library", the first two results you get lead you to the 
package Sam refers to.

I use Google so much that I've set it up as my home page.  :-)

-- Keith

Re: [GUSI] MIT Support Library

[Simon L. <Reishi@Sympatico.ca>]

-Sam:

> If anybody else (like me) can't get GUSI to work they might be interested
> in the MIT support library for clients.

And where can we find some information about this MIT support library?

Thanks,
  Simon

[GUSI] MIT Support Library

[Sam <wa...@ea...>]

If anybody else (like me) can't get GUSI to work they might be interested 
in the MIT support library for clients.

Re: [GUSI] Stalls in GUSIHandleNextEvent

[Jack J. <Jac...@or...>]

On dinsdag, nov 19, 2002, at 14:58 Europe/Amsterdam, John Cebasek wrote:

> Also, is there an 'official' carbonized version of GUSI.  I bit the 
> bullet and carbonized the code (which could be why I'm having the 
> problems...) And what about CW 8 support.  I know some of the headers 
> that GUSI uses have been deprecated, is there a plan to bring GUSI up 
> to CW 8?

If you check out the CVS sources there's a Carbon branch. But building 
GUSI from CVS is not for the faint of heart: you need MPW and MacPerl 
and the MacPerl MPW tool.

There is an unofficial distribution of the source (ready to compile) at 
http://www.cwi.nl/~jack/macpython.html.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [GUSI] Hello world!

[Simon L. <Reishi@Sympatico.ca>]

> I'm not sure exactly what you're asking -- do you just need help compiling
> your project or are you looking for a console library?  In the event of the
> latter, you might be interested in Genie.  It provides console windows with
> a unix-like shell (in progress, but already useful) and allows you to run
> shell scripts and externally compiled commands, which can run in the
> background.  For example, some of my external commands include htget,
> httpd, and telnetd.  If you're interested, you'll probably need assistance,
> or at least some documentation.  Let me know what you need.  The CVS is at
> <http://sf.net/projects/lamp/>.

Yes, I might not have been clear enough, I meant I have difficulties getting
GUSI to work at all, it gives me a lot of compile errors and warnings that I
can't seem to get over (although I know warnings are normal).

I'm already working with the ansi shell provided with CodeWarrior for Mac
projects.

What I would find definately most useful is a working CodeWarrior Pro 7
project using GUSI.  And that because I very new to the Mac and CodeWarrior
(I was on linux before)...

Thanks for your time!
  Simon

Re: [GUSI] Hello world!

[Joshua J. <wan...@me...>]

--On Tuesday, November 19, 2002 5:04 PM -0500 Simon Lemieux 
<Reishi@Sympatico.ca> wrote:

>   I was wondering if anyone could provide me with additionnal help for
> compiling with GUSI.  All I need is an ANSI console for IO (with iostream)
> and any header that will be relevant to TCP networking (I don't still know
> which, I haven't had time to work much on my project yet since I was
> absorbed by trying to make GUSI and CodeWarrior work!)

I'm not sure exactly what you're asking -- do you just need help compiling 
your project or are you looking for a console library?  In the event of the 
latter, you might be interested in Genie.  It provides console windows with 
a unix-like shell (in progress, but already useful) and allows you to run 
shell scripts and externally compiled commands, which can run in the 
background.  For example, some of my external commands include htget, 
httpd, and telnetd.  If you're interested, you'll probably need assistance, 
or at least some documentation.  Let me know what you need.  The CVS is at 
<http://sf.net/projects/lamp/>.

Josh