Hi everyone,
On my current robotics project, I'm using a gumstix verdex to talk over a USB to serial converter chip (FT232) to a serial bus.
My brother Dave made up a new kernel driver for the gumstix, and when I plug in the chip it registers itself as ttyUSB0.
For work I've done previously on Squeak on the gumstix, I've used standard serial ports, which map to ttyS0, ttyS1, ttyS2, etc, which correspond to port 0, 1, and 2 when I open the Serial Port in Squeak. However, I have no idea which port number ttyUSB0 corresponds to...
Anyone got any idea?
Thanks, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
Can you try "cat /proc/devices" with/without the device inserted? Maybe this will indicate the port being added? I'm not on Linux at the moment but it's worth a try.
On Sun, 20 May 2007 07:45:11 +0100, "Derek O'Connell" doconnel@gmail.com wrote:
OTOH, shouldn't it simply be a numbered port? Have you tried 3 or 4?
I'm going to try all the ports between 0 and 9 to see what happens, but first I need to actually get Squeak running on the board -- which isn't working right now - this is a new PXA270-based gumstix verdex and apparently its different enough so I can't run the same VM I run on my old PXA255 gumstix.
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
On Sunday 20 May 2007 5:33 am, Jon Hylands wrote:
Hi everyone, For work I've done previously on Squeak on the gumstix, I've used standard serial ports, which map to ttyS0, ttyS1, ttyS2, etc, which correspond to port 0, 1, and 2 when I open the Serial Port in Squeak. However, I have no idea which port number ttyUSB0 corresponds to...
SerialPort passes a portnumber which gets mapped to /dev/ttyS<n> filename. So the /dev/ttyUSB<n> cannot be accessed through port numbers :-(. ttyS0 and ttyUSB0 are handled by different drivers and I am not sure if they are equivalent at file i/o level.
You could try a trick on the gumstix: rm /dev/ttyS4 && ln -s /dev/ttyUSB0 /dev/ttyS4
and then try to access it as port 4. If /dev/ttyS? is populated automatically on startup, then you will have to put this command immediately after the startup code.
Hope it works .. Subbu
On Sun, 20 May 2007 20:02:41 +0530, subbukk subbukk@gmail.com wrote:
You could try a trick on the gumstix: rm /dev/ttyS4 && ln -s /dev/ttyUSB0 /dev/ttyS4
My brother suggested the same thing (he built me a new verdex VM as well)
So, I did this:
ln -s /dev/ttyUSB0 /dev/ttyS4
and it worked perfectly!
Thanks everyone for your suggestions...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
On 5/20/07, Jon Hylands jon@huv.com wrote:
Hi everyone,
On my current robotics project, I'm using a gumstix verdex to talk over a USB to serial converter chip (FT232) to a serial bus.
My brother Dave made up a new kernel driver for the gumstix, and when I plug in the chip it registers itself as ttyUSB0.
For work I've done previously on Squeak on the gumstix, I've used standard serial ports, which map to ttyS0, ttyS1, ttyS2, etc, which correspond to port 0, 1, and 2 when I open the Serial Port in Squeak. However, I have no idea which port number ttyUSB0 corresponds to...
Anyone got any idea?
I have to scratch this itch :-). This is something I should know but don't.
At a guess, I'd say this is your answer, from usb-serial.c in the Linux kernel:
static struct usb_serial *get_free_serial (struct usb_serial *serial, int num_ports, unsigned int *minor) { unsigned int i, j; int good_spot;
dbg("%s %d", __FUNCTION__, num_ports);
*minor = 0; for (i = 0; i < SERIAL_TTY_MINORS; ++i) { if (serial_table[i]) continue;
good_spot = 1; for (j = 1; j <= num_ports-1; ++j) if ((i+j >= SERIAL_TTY_MINORS) || (serial_table[i+j])) { good_spot = 0; i += j; break; } if (good_spot == 0) continue;
*minor = i; dbg("%s - minor base = %d", __FUNCTION__, *minor); for (i = *minor; (i < (*minor + num_ports)) && (i < SERIAL_TTY_MINORS); ++i) serial_table[i] = serial; return serial; } return NULL; }
I'm assuming that serial_table[] is a list of the ttyUSBn ports, and this just finds a free one starting from ttyUSB0, but somebody smarter than me is going to have to verify this.
Also mentioned somewhere is that the device allocation will appear in the system logs. That's a pretty disgusting way to find the device mappings. Another way would be to iterate through the /dev/ttyUSB*'s to find your device which I find equally disgusting. It's probably easiest to simply assume that it is always /dev/ttyUSB0 or /dev/usb/tts/0 if you're using devfs.
Did Dave write the code, or did he simply compile it? It sounds like he'd be the person to ask, and I'm surprised he didn't make a /dev/microraptor for you :-).
Michael. p.s. I've seen a video of your raptor - it rocks!
Michael van der Gulik wrote:
On 5/20/07, *Jon Hylands* <jon@huv.com mailto:jon@huv.com> wrote:
Hi everyone, On my current robotics project, I'm using a gumstix verdex to talk over a USB to serial converter chip (FT232) to a serial bus. My brother Dave made up a new kernel driver for the gumstix, and when I plug in the chip it registers itself as ttyUSB0. For work I've done previously on Squeak on the gumstix, I've used standard serial ports, which map to ttyS0, ttyS1, ttyS2, etc, which correspond to port 0, 1, and 2 when I open the Serial Port in Squeak. However, I have no idea which port number ttyUSB0 corresponds to... Anyone got any idea?I have to scratch this itch :-). This is something I should know but don't.
At a guess, I'd say this is your answer, from usb-serial.c in the Linux kernel:
..actually sorry; I misread your email.
Michael.
Hello everyone,
I re-open an old topic concerning how some USB->COM converters are mounted by Linux (and MacOS), and why it's a problem for the project I'm working in (SqueakBot, with Serge Stinckwich).
We are using a lot of USB->COM converters (actually, microcontrollers, with USB interfaces, we pilot within Squeak through the serial port) and, as noted by Jon Hylands, they are mounted under Linux as ttyUSBx (and more surprinsingly, ttyUSBModemX under MacOS), and thus not reachable from Squeak (since the Serial communication primitives just append the serial port number to "ttyS" to locate the device). The proposed solution with a virtual link is a valid workaround, but not very usable in our case (the electronic boards are meant to be use by non specialist public, including children, and I can not expect them to type any kind of "ln -s" magic).
A better workaround, for us, would to define a new Squeak primitive in SerialPlugin to open the serial port which takes the full device string ("dev/ttyUSBx") as argument (in this case, the cross-plateform compatibility will have to be ensured in the Squeak code). Do you think it would be feasible? or do you have any other idea?
Thank you! Severin
On Tue, 17 Jun 2008 18:11:53 -0700 (PDT), Skadge skadge@gmail.com wrote:
The proposed solution with a virtual link is a valid workaround, but not very usable in our case (the electronic boards are meant to be use by non specialist public, including children, and I can not expect them to type any kind of "ln -s" magic).
While I agree the new plugin would be nice to have (and I would certainly use it), couldn't you just run the command from Squeak using OSProcess as part of the initialization?
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
While I agree the new plugin would be nice to have (and I would certainly use it), couldn't you just run the command from Squeak using OSProcess as part of the initialization?
Not really because we can have several USB boards connected at the same time, without knowing, a priori, their number (ttyUSBx). We have an automatic detection mechanism : we write on the first 10 COM ports a string and read an answer when one of our board is present. Works fine under Windows, but under Linux or MacOS... I could link *all* the ttyUSB to the corresponding ttyS, but... well... it's a bit dirty :-) and could bring some conflicts if traditional serial devices are plugged and already use the ttySx.
Severin
On Tue, Jun 17, 2008 at 06:11:53PM -0700, Skadge wrote:
A better workaround, for us, would to define a new Squeak primitive in SerialPlugin to open the serial port which takes the full device string ("dev/ttyUSBx") as argument (in this case, the cross-plateform compatibility will have to be ensured in the Squeak code). Do you think it would be feasible? or do you have any other idea?
Severin,
Certainly it is feasible. However, it would be difficult to actually get the changes implemented and released in the "official" VM, simply because of the time it would take to coordinate. So if you can build and release the plugin yourself, then it can be done.
or do you have any other idea?
If you are concerned with Unix/Linux platforms, you can probably just do a change to these two lines in the sqUnixSerial.c support code:
#define PORT_NAME_SIZE 11 static const char serialPortBaseName[] = "/dev/ttyS0";
If you change the serialPortBaseName to the right value for your USB device names, and modify PORT_NAME_SIZE to match, then the plugin will probably do what you want without further modification. No, I have not tested this, and yes it's a hack ;)
A slightly more difficult change would be to add an optional primitive for Unix/Linux that sets the serialPortBaseName string. That would let you control it from Squeak, and would not require any changes to the existing primitives. If you did the changes to implement this for Unix, you would have a reasonable chance of getting them included in future VM releases, because the changes would be backward-compatible and would require testing only for Unix based platforms.
Note, I have no experience programming USB ports, so I'm assuming from your original question that the SerialPlugin actually works when connected to a USB device rather than to a traditional serial port.
Dave
Thanks, Dave, for the answer.
A slightly more difficult change would be to add an optional primitive for Unix/Linux that sets the serialPortBaseName string. That would let you control it from Squeak, and would not require any changes to the existing primitives.
That's actually probably what I'll try to do. Stupid question, but where can I fetch the sqUnixSerial.c file (and it's MacOS counterpart)?
Severin
On Wed, Jun 18, 2008 at 04:10:39AM +0100, S??verin Lemaignan wrote:
Thanks, Dave, for the answer.
A slightly more difficult change would be to add an optional primitive for Unix/Linux that sets the serialPortBaseName string. That would let you control it from Squeak, and would not require any changes to the existing primitives.
That's actually probably what I'll try to do. Stupid question, but where can I fetch the sqUnixSerial.c file (and it's MacOS counterpart)?
Severin,
The sqUnixSerial.c file is part of the external support code (as opposed to the parts that are distributed in the VMMaker package). The external support code is maintained in a Subversion repository at http://squeakvm.org and you will also find it at the various VM home pages. If you are working with Linux for example, just grab one of Ian's distributions on http://squeakvm.org/unix/.
The sqUnixSerial.c file is in platforms/unix/plugins/SerialPlugin. The corresponding support code for other platforms is in e.g. platforms/Mac OS/plugins/serialPlugin.
I don't know enough about Mac OS to give any guidance there, but the support code for SerialPlugin looks like it might be for some older version of Mac OS. I understand that on OS X you can actually use a plugin from the unix sources, but I'm afraid I don't know the details.
Dave
Hello everyone,
A couple of months later, I'm eventually working on getting the SerialPort plugin to work for arbitrary nodes name under Linux (and thus MacOS).
A quick summary of the issue, to refresh memories: today, you can open a serial port in Squeak with "SerialPort new openPort:portNum.". Eg, for portNum = 1, it would map to COM1 under Windows and /dev/ttyS1 under Linux. That's fine, except that recent Linux kernels don't mount most serial devices on /dev/ttySxx, but on more specific nodes, like /dev/ttyACMxx for modems, /dev/ttyUSBxx for certain USB->COM converters, etc.
To circumvent it, I modified the Serial Port plugin to accept either port numbers or arbitrary paths. I still have some cleaning to do, but the plugin itself (sqUnixSerial.c) basically works. But I have some troubles to get it to work from Squeak. I modified SqueakPlugin.c to introduce new primitive calls (plus their corresponding "exports" declaration), namely: EXPORT(sqInt) primitiveSerialPortCloseByName(void); EXPORT(sqInt) primitiveSerialPortOpenByName(void); EXPORT(sqInt) primitiveSerialPortReadByName(void); EXPORT(sqInt) primitiveSerialPortWriteByName(void);
For each of them, I need to get the port name. I did like that (copy-pasted from another plugin):
int spName; char * spNameIndex;
spName = interpreterProxy->stackValue(0); interpreterProxy->success(interpreterProxy->isBytes(spName)); spNameIndex = interpreterProxy->firstIndexableField(spName);
But I probably do something wrong since if I call the primitive "primSerialPortOpenByName" with "/dev/ttyACM0" as port name from Squeak, the plugin code in sqUnixSerial.c receives a different string ("/dev/ttyACM0_��@�w@�w"), thus failing to open the serial port.
Does someone knows how to correctly transmit a string argument to a plugin?
I attach to the mail my working versions of sqUnixSerial.c, SerialPlugin.c, SerialPlugin.h. If needed, I can send as well some test code for sqUnixSerial.c.
And by the way, happy new year to everybody!
Séverin
2008/6/18 David T. Lewis lewis@mail.msen.com:
On Wed, Jun 18, 2008 at 04:10:39AM +0100, S??verin Lemaignan wrote:
Thanks, Dave, for the answer.
A slightly more difficult change would be to add an optional primitive for Unix/Linux that sets the serialPortBaseName string. That would let you control it from Squeak, and would not require any changes to the existing primitives.
That's actually probably what I'll try to do. Stupid question, but where can I fetch the sqUnixSerial.c file (and it's MacOS counterpart)?
Severin,
The sqUnixSerial.c file is part of the external support code (as opposed to the parts that are distributed in the VMMaker package). The external support code is maintained in a Subversion repository at http://squeakvm.org and you will also find it at the various VM home pages. If you are working with Linux for example, just grab one of Ian's distributions on http://squeakvm.org/unix/.
The sqUnixSerial.c file is in platforms/unix/plugins/SerialPlugin. The corresponding support code for other platforms is in e.g. platforms/Mac OS/plugins/serialPlugin.
I don't know enough about Mac OS to give any guidance there, but the support code for SerialPlugin looks like it might be for some older version of Mac OS. I understand that on OS X you can actually use a plugin from the unix sources, but I'm afraid I don't know the details.
Dave
On Sun, Jan 04, 2009 at 11:54:22PM +0100, S??verin Lemaignan wrote:
For each of them, I need to get the port name. I did like that (copy-pasted from another plugin):
int spName; char * spNameIndex; spName = interpreterProxy->stackValue(0); interpreterProxy->success(interpreterProxy->isBytes(spName)); spNameIndex = interpreterProxy->firstIndexableField(spName);But I probably do something wrong since if I call the primitive "primSerialPortOpenByName" with "/dev/ttyACM0" as port name from Squeak, the plugin code in sqUnixSerial.c receives a different string ("/dev/ttyACM0_??????@???w@???w"), thus failing to open the serial port.
Does someone knows how to correctly transmit a string argument to a plugin?
S??verin,
The trick here is that C expects strings to be null-terminated, and the Squeak string that you pass to the primitive does not have the trailing null.
In general, you will want to copy the Squeak string contents into a freshly allocated char[] array of size one greater than the string length. There are a number of ways you can do this, but to give some examples you can look in OSProcessPlugin (available on SqueakSource in project OSProcessPlugin). The methods #transientCStringFromString: and #cStringFromString: provide two ways to do the conversion. As an example, here is a primitive from UnixOSProcessPlugin after it has been converted from Slang to C:
/* Call chdir(2) to change current working directory to the specified path string. Answer nil for success, or errno on failure. */
EXPORT(sqInt) primitiveChdir(void) { extern int errno; char * path; sqInt aString; sqInt len; char *cString; char *stringPtr; sqInt newString;
/* begin transientCStringFromString: */ aString = interpreterProxy->stackObjectValue(0); len = interpreterProxy->sizeOfSTArrayFromCPrimitive(interpreterProxy->arrayValueOf(aString)); interpreterProxy->pushRemappableOop(aString); newString = interpreterProxy->instantiateClassindexableSize(interpreterProxy->classString(), len + 1); stringPtr = interpreterProxy->arrayValueOf(interpreterProxy->popRemappableOop()); cString = interpreterProxy->arrayValueOf(newString); (char *)strncpy(cString, stringPtr, len); cString[len] = 0; path = cString; if (chdir(path)) { interpreterProxy->pop(2); interpreterProxy->push(interpreterProxy->nilObject()); } else { interpreterProxy->pop(2); interpreterProxy->pushInteger(errno); } }
And by the way, happy new year to everybody!
And to you as well!
- Dave
Thanks Dave, it works. ...its...hum... not straighforward! :)
I'll finnish to debug and clean the code tomorrow, and I hope to be able to quickly release a patch.
What's the procedure to get the patch reviewed and possibly included in the trunk (including the OLPC Etoys branch)?
Bye, Séverin
On Mon, Jan 5, 2009 at 00:46, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jan 04, 2009 at 11:54:22PM +0100, S??verin Lemaignan wrote:
For each of them, I need to get the port name. I did like that (copy-pasted from another plugin):
int spName; char * spNameIndex; spName = interpreterProxy->stackValue(0); interpreterProxy->success(interpreterProxy->isBytes(spName)); spNameIndex = interpreterProxy->firstIndexableField(spName);But I probably do something wrong since if I call the primitive "primSerialPortOpenByName" with "/dev/ttyACM0" as port name from Squeak, the plugin code in sqUnixSerial.c receives a different string ("/dev/ttyACM0_?????? @???w @???w "), thus failing to open the serial port.
Does someone knows how to correctly transmit a string argument to a plugin?
S??verin,
The trick here is that C expects strings to be null-terminated, and the Squeak string that you pass to the primitive does not have the trailing null.
In general, you will want to copy the Squeak string contents into a freshly allocated char[] array of size one greater than the string length. There are a number of ways you can do this, but to give some examples you can look in OSProcessPlugin (available on SqueakSource in project OSProcessPlugin). The methods #transientCStringFromString: and #cStringFromString: provide two ways to do the conversion. As an example, here is a primitive from UnixOSProcessPlugin after it has been converted from Slang to C:
/* Call chdir(2) to change current working directory to the specified path string. Answer nil for success, or errno on failure. */
EXPORT(sqInt) primitiveChdir(void) { extern int errno; char * path; sqInt aString; sqInt len; char *cString; char *stringPtr; sqInt newString;
/* begin transientCStringFromString: */ aString = interpreterProxy->stackObjectValue(0); len = interpreterProxy->sizeOfSTArrayFromCPrimitive(interpreterProxy->arrayValueOf(aString)); interpreterProxy->pushRemappableOop(aString); newString = interpreterProxy->instantiateClassindexableSize(interpreterProxy->classString(), len + 1); stringPtr = interpreterProxy->arrayValueOf(interpreterProxy->popRemappableOop()); cString = interpreterProxy->arrayValueOf(newString); (char *)strncpy(cString, stringPtr, len); cString[len] = 0; path = cString; if (chdir(path)) { interpreterProxy->pop(2); interpreterProxy->push(interpreterProxy->nilObject()); } else { interpreterProxy->pop(2); interpreterProxy->pushInteger(errno); }}
And by the way, happy new year to everybody!
And to you as well!
- Dave
On Mon, Jan 05, 2009 at 01:23:07AM +0100, S??verin Lemaignan wrote:
Thanks Dave, it works. ...its...hum... not straighforward! :)
I'll finnish to debug and clean the code tomorrow, and I hope to be able to quickly release a patch.
What's the procedure to get the patch reviewed and possibly included in the trunk (including the OLPC Etoys branch)?
S??verin,
Good question. I'm not sure if there is an "official" process for this, but what I would suggest is to open a bug report on Mantis (bugs.squeak.org) and upload your patches there. Then mention the bug report here on the list, and also on the vm-dev list (http://lists.squeakfoundation.org/pipermail/vm-dev).
The primary VM developers watch the vm-dev list (somewhat intermittently) so that will be the best place to figure out how to get your fixes into the Subversion repository.
Dave
Ok, I've submitted a bug (http://bugs.squeak.org/view.php?id=7266) concerning the serial port issue. I attached along my patch. I don't know how to extract a patch from the Squeak image to distribute the required modifications to the SerialPort class, but if someone explains, I'll happily add it to the bug report.
Bye, Séverin
S??verin,
Good question. I'm not sure if there is an "official" process for this, but what I would suggest is to open a bug report on Mantis (bugs.squeak.org) and upload your patches there. Then mention the bug report here on the list, and also on the vm-dev list (http://lists.squeakfoundation.org/pipermail/vm-dev).
The primary VM developers watch the vm-dev list (somewhat intermittently) so that will be the best place to figure out how to get your fixes into the Subversion repository.
Dave
http://vimeo.com/groups/squeak/videos/1495355
Also see the project documentation on http://bugs.squeak.org/ by clicking 'docs' in the link list near the top.
Ken
On Tue, 2009-01-13 at 00:48 +0100, Séverin Lemaignan wrote:
Ok, I've submitted a bug (http://bugs.squeak.org/view.php?id=7266) concerning the serial port issue. I attached along my patch. I don't know how to extract a patch from the Squeak image to distribute the required modifications to the SerialPort class, but if someone explains, I'll happily add it to the bug report.
Bye, Séverin
S??verin,
Good question. I'm not sure if there is an "official" process for this, but what I would suggest is to open a bug report on Mantis (bugs.squeak.org) and upload your patches there. Then mention the bug report here on the list, and also on the vm-dev list (http://lists.squeakfoundation.org/pipermail/vm-dev).
The primary VM developers watch the vm-dev list (somewhat intermittently) so that will be the best place to figure out how to get your fixes into the Subversion repository.
Dave
Ok, thanks. ChangeSet added to the bu report.
Séverin
On Tue, Jan 13, 2009 at 01:42, Ken Causey ken@kencausey.com wrote:
http://vimeo.com/groups/squeak/videos/1495355
Also see the project documentation on http://bugs.squeak.org/ by clicking 'docs' in the link list near the top.
Ken
So I figured out what was causing the world menus to disappear in Croquet. And this is different from the unresponsive 3.10.2 images on Vista. I know this isn't the Croquet list, I am just adding some closure here on one of the issues I raised in the newbies thread.
The problem is simple: several of the themes (appearance -> theme...) available in the Croquet zip file cause the world menus to disappear. [I will look into the details later tonight.]
Specifically, on all three Vista computers here, the themes "keihanna", "takanawa", and "westwood" cause the world menus to not be raised when invoked by mouse clicks. [The menu raised by escape generally works, but did fail in one case.] If you have pinned one of the world menus (or appearance menus) to the background, or have a workspace open, you can simply select one of the other themes to get the windows back; specifically: "outOfTheBox", "personal", "paloAlto", and "smalltalk80" all restore the world menus to the expected behavior.
This was hard for me to discover, because 1) I hadn't spend a lot of time in Croquet until everybody informed me how alpha-ish Pharo and 3.10 are, and 2) many times I wouldn't set the themes, and when I did, there was only a 3 out of 6 chance I last-selected one of the bad ones (I never chose smalltalk80 because of the strong warnings about losing the flaps), and when I did, I did not always immediately reach for a root menu - perhaps because I started pinning menus up after they appeared to be flaky.
-- What a relief... just when I was about to give up on the Croquet release. So, it seems that Croquet may work for me. I will put in some time and see if I can find some pattern to the "Vista ignorance" (of mouse and keyboard events) in 3.10.2.
-Cam
Hi Cameron -
I don't recall seeing your messages otherwise I would have responded earlier. The problem you are seeing comes from the fact that some of the preference themes enable the "eToyFriendly" mode. In this mode, the world menu is deliberately disabled and only accessible via Alt-Shift-W. If you select such a preference theme and then disable "eToyFriendly" (in the "scripting" category) the world menu will be back.
Cheers, - Andreas
Cameron Sanders wrote:
So I figured out what was causing the world menus to disappear in Croquet. And this is different from the unresponsive 3.10.2 images on Vista. I know this isn't the Croquet list, I am just adding some closure here on one of the issues I raised in the newbies thread.
The problem is simple: several of the themes (appearance -> theme...) available in the Croquet zip file cause the world menus to disappear. [I will look into the details later tonight.]
Specifically, on all three Vista computers here, the themes "keihanna", "takanawa", and "westwood" cause the world menus to not be raised when invoked by mouse clicks. [The menu raised by escape generally works, but did fail in one case.] If you have pinned one of the world menus (or appearance menus) to the background, or have a workspace open, you can simply select one of the other themes to get the windows back; specifically: "outOfTheBox", "personal", "paloAlto", and "smalltalk80" all restore the world menus to the expected behavior.
This was hard for me to discover, because 1) I hadn't spend a lot of time in Croquet until everybody informed me how alpha-ish Pharo and 3.10 are, and 2) many times I wouldn't set the themes, and when I did, there was only a 3 out of 6 chance I last-selected one of the bad ones (I never chose smalltalk80 because of the strong warnings about losing the flaps), and when I did, I did not always immediately reach for a root menu - perhaps because I started pinning menus up after they appeared to be flaky.
-- What a relief... just when I was about to give up on the Croquet release. So, it seems that Croquet may work for me. I will put in some time and see if I can find some pattern to the "Vista ignorance" (of mouse and keyboard events) in 3.10.2.
-Cam
Thank you Andreas, you just saved me some time! You also gave me a path out of that situation: Alt-Shift-W. And you gave me more clues to guide my explorations of Squeak -- thank you. So much to learn... Cheers! -Cam
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Monday, January 12, 2009 11:19 PM To: The general-purpose Squeak developers list Subject: [squeak-dev] Re: Vista / CroquetSDK-1.0.18 / how to lose the world menu in 5 seconds or less
Hi Cameron -
I don't recall seeing your messages otherwise I would have responded earlier. The problem you are seeing comes from the fact that some of the preference themes enable the "eToyFriendly" mode. In this mode, the world menu is deliberately disabled and only accessible via Alt-Shift-W. If you select such a preference theme and then disable "eToyFriendly" (in the "scripting" category) the world menu will be back.
Cheers, - Andreas
Cameron Sanders wrote:
So I figured out what was causing the world menus to disappear in Croquet. And this is different from the unresponsive 3.10.2 images on Vista. I know this isn't the Croquet list, I am just adding some closure here on one of the issues I raised in the newbies thread.
I *suspect* I could safely provide closure to the Pharo0.1 image lock ups -- although I will do some testing with before calling the case closed -- as I was using the Squeak 3.10.2 VM. I have the impression that should be 3.9.1 ... sorry, I somehow missed the labeling... or still have.
...
Thanks again. Cheers, Cam
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Cameron Sanders -
David T. Lewis -
Derek O'Connell -
Jon Hylands -
Ken Causey -
Michael van der Gulik -
Michael van der Gulik -
Skadge -
subbukk -
Séverin Lemaignan