[squeak-dev] unsubscribeYassine.Khlifi at bull.net Yassine.Khlifi at bull.netWed Mar 25 12:54:10 UTC 2009
Yassine Khlifi Bull, Architect of an Open World TM Centre De Services Paris e-mail: yassine.khlifi at bull.net tel : 01-69-93-92-92 (223-9292) site : http://www.bull.com |---------+---------------------------------------------> | | squeak-dev-request at lists.squeakfou| | | ndation.org | | | Envoyé par : | | | squeak-dev-bounces at lists.squeakfou| | | ndation.org | | | | | | | | | 25/03/2009 12:58 | | | Veuillez répondre à squeak-dev | | | | |---------+---------------------------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | Pour : squeak-dev at lists.squeakfoundation.org | | cc : | | Objet : Squeak-dev Digest, Vol 75, Issue 43 | >-------------------------------------------------------------------------------------------------------------------------------| Send Squeak-dev mailing list submissions to squeak-dev at lists.squeakfoundation.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev or, via email, send a message with subject or body 'help' to squeak-dev-request at lists.squeakfoundation.org You can reach the person managing the list at squeak-dev-owner at lists.squeakfoundation.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Squeak-dev digest..." Today's Topics: 1. WorldState deferredUIMessages queue (Chris Muller) 2. Re: WorldState deferredUIMessages queue (Andreas Raab) 3. Re: WorldState deferredUIMessages queue (Andreas Raab) 4. Re: [bug] xor: is this an old bug or what? (Eliot Miranda) 5. Re: Re: WorldState deferredUIMessages queue (Bert Freudenberg) 6. Re: Re: How to get a list of all plugins in VM (Andreas Raab) (Igor Stasenko) 7. Re: WorldState deferredUIMessages queue (Andreas Raab) 8. Re: Re: WorldState deferredUIMessages queue (Igor Stasenko) 9. Re: Re: OSProcess capabilities on Windows (UZONYI Levente) 10. Agenda for Board meeting March 26th 2009 (Andreas Raab) 11. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Aran Lunzer) 12. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Andreas Raab) 13. Re: [bug] xor: is this an old bug or what? (Klaus D. Witzel) 14. How to tell if you have a boolean when you care to know (Jerome Peace) 15. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Aran Lunzer) 16. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Andreas Raab) 17. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Aran Lunzer) 18. Re: Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Simon Kirk) 19. Re: Newbie Questions (Keith Hodges) 20. Monticello compatibility (was Re: Newbie Questions) (Bert Freudenberg) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Mar 2009 16:17:37 -0500 From: Chris Muller <ma.chris.m at gmail.com> Subject: [squeak-dev] WorldState deferredUIMessages queue To: squeak dev <squeak-dev at lists.squeakfoundation.org> Message-ID: <1ac5f6d0903241417h59b47a76o3142401a0a852f35 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 (3.9 Morphic). With Maui I occassionally get World lockups due to the UI process waiting for the #next of the deferredUIMessages, which is empty. Specifically, the freeze, when it occurs, is always in WorldState>>#runStepMethodsIn:. There's a while loop to process messages in the queue: "Dispatch deferred messages while maintaing rudimentary UI responsiveness." [i < numItems and: [(Time millisecondsSince: stamp) < limit]] whileTrue: [queue next value. i := i + 1]. and its hung waiting for "queue next". But it seems like this shouldn't be possible because, at the top of the method, "numItems" is set to the size of the queue. numItems := queue size. and so the only explanation is, somehow in processing one of the messages, it causes another one to be removed from the queue. This appears to be possible if the first message calls a #doOneCycle, leading it back through this same method.. I do have 4 or 5 #doOneCycles sprinkled around, in order to force correct layout or screen redraws. I'm pretty sure these are causing the deadlock but.. when I tried taking some of them out I get the layout/redraw problem.. Any advice is greatly appreciated. - Chris ------------------------------ Message: 2 Date: Tue, 24 Mar 2009 14:37:26 -0700 From: Andreas Raab <andreas.raab at gmx.de> Subject: [squeak-dev] Re: WorldState deferredUIMessages queue To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <49C95296.1030208 at gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Chris Muller wrote: > (3.9 Morphic). With Maui I occassionally get World lockups due to the > UI process waiting for the #next of the deferredUIMessages, which is > empty. > > Specifically, the freeze, when it occurs, is always in > WorldState>>#runStepMethodsIn:. There's a while loop to process > messages in the queue: > > "Dispatch deferred messages while maintaing rudimentary UI responsiveness." > [i < numItems and: [(Time millisecondsSince: stamp) < limit]] > whileTrue: [queue next value. i := i + 1]. This is plain wrong. I don't know what the rationale of the change was but you'll have much better success if you change this to e.g., queue := self class deferredUIMessages. [(msg := queue nextOrNil) == nil] whileFalse: [ msg value. ]. The reason why the original version is wrong is that there is absolutely no assurance that some Morph won't call World doOneCycle which would re-enter the above loop, pull out all of the events and leave the original caller hanging; just as you report. Cheers, - Andreas ------------------------------ Message: 3 Date: Tue, 24 Mar 2009 14:43:24 -0700 From: Andreas Raab <andreas.raab at gmx.de> Subject: [squeak-dev] Re: WorldState deferredUIMessages queue To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <49C953FC.70405 at gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Chris Muller wrote: > Any advice is greatly appreciated. Actually, here is a fun test to exercise the problem: testDoOneCycleWorksWithDeferredQueue "Ensure that nested doOneCycles don't break deferred UI messages" | finished | [ WorldState addDeferredUIMessage:[World doOneCycleNow]. WorldState addDeferredUIMessage:["whatever"]. World doOneCycleNow. finished := true. ] valueWithin: 1 second onTimeout:[finished := false]. self assert: finished Cheers, - Andreas ------------------------------ Message: 4 Date: Tue, 24 Mar 2009 15:01:45 -0700 From: Eliot Miranda <eliot.miranda at gmail.com> Subject: Re: [squeak-dev] [bug] xor: is this an old bug or what? To: "Randal L. Schwartz" <merlyn at stonehenge.com> Cc: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <3ac5ce8a0903241501k73fafc2ei142aa2000d4d436a at mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Tue, Mar 24, 2009 at 1:36 PM, Randal L. Schwartz <merlyn at stonehenge.com>wrote: > >>>>> "Eliot" == Eliot Miranda <eliot.miranda at gmail.com> writes: > > Eliot> I think just > > True> xor: aBoolean > Eliot> ^aBoolean not > > False> xor: aBoolean > Eliot> ^aBoolean > > Eliot> and then leave subsequent usage to catch possible type errors; e.g. > (false > Eliot> xor: #blah) ifTrue: ... will raise a mustBeBoolean error. > > What I don't like about this is that the right operand doesn't get a chance > to > "boolify" itself, or define its own xor logic. The double-dispatch > versions > were a lot better at that. If you want to do that you could implement it as False> xor: aBoolean ^aBoolean not not but I'd argue that isn't necessary. The old code didn't type check and we've lived with it for a loooong time. But in any case, the not is a form of double-dispatch. It just points out that one can use not instead of xorTrue and is more comprehensible because "not" is familiar. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside > discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090324/fd3aecb9/attachment-0001.htm ------------------------------ Message: 5 Date: Tue, 24 Mar 2009 23:13:27 +0100 From: Bert Freudenberg <bert at freudenbergs.de> Subject: Re: [squeak-dev] Re: WorldState deferredUIMessages queue To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <C8C480F0-0CC0-43BB-98AF-F0E060733866 at freudenbergs.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On 24.03.2009, at 22:37, Andreas Raab wrote: > Chris Muller wrote: >> (3.9 Morphic). With Maui I occassionally get World lockups due to >> the >> UI process waiting for the #next of the deferredUIMessages, which is >> empty. >> Specifically, the freeze, when it occurs, is always in >> WorldState>>#runStepMethodsIn:. There's a while loop to process >> messages in the queue: >> "Dispatch deferred messages while maintaing rudimentary UI >> responsiveness." >> [i < numItems and: [(Time millisecondsSince: stamp) < limit]] >> whileTrue: [queue next value. i := i + 1]. > > This is plain wrong. I don't know what the rationale of the change > was but you'll have much better success if you change this to e.g., > > queue := self class deferredUIMessages. > [(msg := queue nextOrNil) == nil] whileFalse: [ > msg value. > ]. > > The reason why the original version is wrong is that there is > absolutely no assurance that some Morph won't call World doOneCycle > which would re-enter the above loop, pull out all of the events and > leave the original caller hanging; just as you report. FWIW, the 3.8 method looked like this: [queue isEmpty] whileFalse: [queue next value]. - Bert - ------------------------------ Message: 6 Date: Wed, 25 Mar 2009 00:16:04 +0200 From: Igor Stasenko <siguctua at gmail.com> Subject: Re: [squeak-dev] Re: How to get a list of all plugins in VM (Andreas Raab) To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <4a5f5f320903241516r6392ca88s356944e4a1ca90dd at mail.gmail.com> Content-Type: text/plain; charset=UTF-8 2009/3/24 Maarten Maartensz <maartens at xs4all.nl>: > Hello Andreas, > > Long time, no see but I still follow Squeak and my Squeak Help on my site. See > > http://www.maartensz.org/computing/computingFrame.htm > > which I wrote for Squeak 3.7 is still used daily on my site by quite a few > visitors, so apparently it still satisfies a need. > > My main reason to keep following Squeak is interest (it looks a lot better now > than a few years ago) in HLL, Smalltalk and Morphic, but my own main interest in > computing and programming these days is mostly in assembly. > > And this caused my answering this thread, though it doesn't answer Ross Boylan's > question for Linux, which I don't run. > > You wrote, in reply to him: > >> Ross Boylan wrote: >> > I'm trying to figure out if I'm setup so I can use some of the font >> > packages.  I'm running a 3.10 image (but 3.9 VM) on Linux (Debian >> > Lenny). >> > >> > How do I get a list of all plugins? >> >> You don't. External, unloaded plugins can't be enumerated since they are >> just platform shared libraries (DLLs). They could be found anywhere in >> your search path which makes it very difficult to list them explicitly. > > On Windows, though, there are nifty great and small assembly-related programs > that answer many queries, also about what is really there in Squeak.exe, all > laid out neatly. > > A great one for this (also in size and capacities) is OllyDbg, by Oleg Yushuck; > a small one (idem) is PEView by Wayne Radburn. Both are at various places on the > internet, and easily found with Google. > > The last one is most convenient here. The one I used  is 0.9.8.0 that takes - > unzipped - all of 67 Kb (it's programmed in assembly, you see, and there is no > image at all...) which neatly shows in its SECTION.edata (e.g. EXPORT Address > Table) which primitives are in the executable. Likewise, its SECTION.idata > displays the loaded DLLs. > > To find this and much more, all one needs is PEView and opening Squeak.exe in > it, which then lists it quite neatly. If one knows some C or Assembly this is > all > quite revealing and interesting, and one item to be found thus at various places > is e.g. "Andreas Raab", at least in the version of Squeak.exe I inspected this > way. > > In any case... some questions about Squeak.exe can definitely be answered quite > easily and fastly on Windows using PEView. > Why use reverse engineering tools, where its more appropriate to use reflection? > Regards, > > Maarten. > > >>  13.  Re: How to get a list of all plugins in VM (Andreas Raab) >> Message: 13 >> Date: Mon, 23 Mar 2009 15:55:29 -0700 >> From: Andreas Raab <andreas.raab at gmx.de> >> Subject: [squeak-dev] Re: How to get a list of all plugins in VM >> To: The general-purpose Squeak developers list >> <squeak-dev at lists.squeakfoundation.org> >> Cc: ross at biostat.ucsf.edu >> Message-ID: <49C81361.7040308 at gmx.de> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Ross Boylan wrote: >> > I'm trying to figure out if I'm setup so I can use some of the font >> > packages.  I'm running a 3.10 image (but 3.9 VM) on Linux (Debian >> > Lenny). >> > >> > How do I get a list of all plugins? >> >> You don't. External, unloaded plugins can't be enumerated since they are >> just platform shared libraries (DLLs). They could be found anywhere in >> your search path which makes it very difficult to list them explicitly. >> >> The right way to solve your problem is to provide an entry point in your >> plugin that can be used to detect whether the plugin is available. A >> useful thing to do here is to provide a primitiveVersion because later >> on you'll be able to use that to detect whether the user has an outdated >> plugin version. Then you can simply implement something like: >> >> MyClass>>pluginVersion >> "Returns the plugin version, or nil if the plugin cannot be loaded" >> <primitive: 'primitiveVersion' module: 'MyPlugin'> >> ^nil "indicates failure" >> >> MyClass>>isPluginPresent >> "Returns true if the plugin is present" >> ^self pluginVersion notNil >> >> MyClass>>isPluginOfTheRightVersion >> "Returns true if the plugin is of the right version" >> ^(self pluginVersion ifNil:[0]) > self minimumVersion >> >> Cheers, >>   - Andreas >> >> >> ------------------------------ > > > > -- Best regards, Igor Stasenko AKA sig. ------------------------------ Message: 7 Date: Tue, 24 Mar 2009 15:18:01 -0700 From: Andreas Raab <andreas.raab at gmx.de> Subject: [squeak-dev] Re: WorldState deferredUIMessages queue To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <49C95C19.2070107 at gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Bert Freudenberg wrote: > On 24.03.2009, at 22:37, Andreas Raab wrote: >> Chris Muller wrote: >>> (3.9 Morphic). With Maui I occassionally get World lockups due to the >>> UI process waiting for the #next of the deferredUIMessages, which is >>> empty. >>> Specifically, the freeze, when it occurs, is always in >>> WorldState>>#runStepMethodsIn:. There's a while loop to process >>> messages in the queue: >>> "Dispatch deferred messages while maintaing rudimentary UI >>> responsiveness." >>> [i < numItems and: [(Time millisecondsSince: stamp) < limit]] >>> whileTrue: [queue next value. i := i + 1]. >> >> This is plain wrong. I don't know what the rationale of the change was >> but you'll have much better success if you change this to e.g., >> >> queue := self class deferredUIMessages. >> [(msg := queue nextOrNil) == nil] whileFalse: [ >> msg value. >> ]. >> >> The reason why the original version is wrong is that there is >> absolutely no assurance that some Morph won't call World doOneCycle >> which would re-enter the above loop, pull out all of the events and >> leave the original caller hanging; just as you report. > > > FWIW, the 3.8 method looked like this: > > [queue isEmpty] whileFalse: [queue next value]. > Which is not entirely safe either since there can a contention for the queue inbetween #isEmpty and #next. We found this when we were still using Morphic worlds in Croquet that would execute concurrently (bad idea ;-) Cheers - Andreas ------------------------------ Message: 8 Date: Wed, 25 Mar 2009 00:21:52 +0200 From: Igor Stasenko <siguctua at gmail.com> Subject: Re: [squeak-dev] Re: WorldState deferredUIMessages queue To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <4a5f5f320903241521v114378abyd3e00246dd9e945c at mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hmm.. what purpose of timestamp there? Both variants (3.8 and Andreas) don't checking it. Maybe the purspose of change were to include the timestamp checking, but it was introduced a bug with incorrent queue handling. 2009/3/25 Andreas Raab <andreas.raab at gmx.de>: > Bert Freudenberg wrote: >> >> On 24.03.2009, at 22:37, Andreas Raab wrote: >>> >>> Chris Muller wrote: >>>> >>>> (3.9 Morphic).  With Maui I occassionally get World lockups due to the >>>> UI process waiting for the #next of the deferredUIMessages, which is >>>> empty. >>>> Specifically, the freeze, when it occurs, is always in >>>> WorldState>>#runStepMethodsIn:.  There's a while loop to process >>>> messages in the queue: >>>>   "Dispatch deferred messages while maintaing rudimentary UI >>>> responsiveness." >>>>   [i < numItems and: [(Time millisecondsSince: stamp) < limit]] >>>>     whileTrue: [queue next value. i := i + 1]. >>> >>> This is plain wrong. I don't know what the rationale of the change was >>> but you'll have much better success if you change this to e.g., >>> >>>   queue := self class deferredUIMessages. >>>   [(msg := queue nextOrNil) == nil] whileFalse: [ >>>     msg value. >>>   ]. >>> >>> The reason why the original version is wrong is that there is absolutely >>> no assurance that some Morph won't call World doOneCycle which would >>> re-enter the above loop, pull out all of the events and leave the original >>> caller hanging; just as you report. >> >> >> FWIW, the 3.8 method looked like this: >> >>   [queue isEmpty] whileFalse: [queue next value]. >> > > Which is not entirely safe either since there can a contention for the queue > inbetween #isEmpty and #next. We found this when we were still using Morphic > worlds in Croquet that would execute concurrently (bad idea ;-) > > Cheers >  - Andreas > > -- Best regards, Igor Stasenko AKA sig. ------------------------------ Message: 9 Date: Wed, 25 Mar 2009 00:35:25 +0100 (CET) From: UZONYI Levente <leves at elte.hu> Subject: Re: [squeak-dev] Re: OSProcess capabilities on Windows To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <Pine.LNX.4.64.0903250020580.10287 at login01.caesar.elte.hu> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi! > So... I tried installing it, but none of my 3.7 images (on XP or on Vista) > could work with the ready-built DLL. Not even the out-of-the-box 3.7 > release. The 3.9 release image seemed much happier: the precise example > you gave here didn't work as I was expecting, but the basic example on the > SqueakSource summary page did: > > ProcessWrapper new > useStdout; > startWithShellCommand: 'echo hello'; > upToEnd > > --> 'hello<cr>' > To make sure that the given example works as expected, you have to make sure that cat (cat.exe) is in the vm's search path, or you have to use the explicit path to the executable, like here: p := ProcessWrapper new useStdout; startWithCommand: 'C:\UnxUtils\usr\local\wbin\cat.exe'; yourself. p writeToStdin: 'foo'. self assert: (p next: 3) = 'foo'. p closeStdin. If you don't have cat.exe (because windows doesn't have it by default), you can download the unxutils package which contains it from: http://unxutils.sourceforge.net/ If you have cat.exe and touch.exe in the vm's search path, then you can run the tests in the package which should all be green. Cheers, Levente ------------------------------ Message: 10 Date: Tue, 24 Mar 2009 19:33:18 -0700 From: Andreas Raab <andreas.raab at gmx.de> Subject: [squeak-dev] Agenda for Board meeting March 26th 2009 To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <49C997EE.9050908 at gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Folks - The agenda for our next board meeting is available at http://squeakboard.wordpress.com/2009/03/25/agenda-for-march-26th-2009/ If you have issues you'd like to put on the list (either for now or later) please bring them up here or as a follow-up on the above post. Cheers, - Andreas ------------------------------ Message: 11 Date: Wed, 25 Mar 2009 12:20:00 +0900 (JST) From: "Aran Lunzer" <aran at meme.hokudai.ac.jp> Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] To: squeak-dev at lists.squeakfoundation.org Message-ID: <446667664469f0ab1fe06112354aee47.squirrel at km.meme.hokudai.ac.jp> Content-Type: text/plain;charset=iso-2022-jp Andreas wrote: >Aran Lunzer wrote: >> Looking at the source code for the DLL, I'm afraid that at the level of my >> non-Squeak skills it would probably take me a day to rebuild it. Do you >> happen to have a 3.7-specific compiled DLL? > >It is extremely unlikely that the problem is with the DLL. More likely >you are switching between VMs that are not compatible with this version. >Try running your 3.7 images with a more recent VM and see if this works >with the DLL in question. Back in my original message about OSProcess I mentioned that I'm working with a 3.7 Web-browser-plugin VM that has been customised (to do various things in support of the .NET bridge). If I can't persuade ProcessWrapper to work with that, I can't use it. At least, not this year :-) I did a little more testing and, as you suggested, the more recent VM helped: the out-of-the-box 3.8 release (6665), for example, couldn't load the ProcessWrapper DLL with its standard VM (Nov 2003), but could when I wheeled in the VM from 3.9. So it seems that something has changed in the VMs, and that something in the DLL only works with new ones. But given that Balasz said that they had used ProcessWrapper with 3.7, I wondered whether they had - or could recompile - a version of the DLL that would be compatible with an old VM. What has changed in the VM wrt DLL loading? Something to do with 64/32-bit support, perhaps? All the best - Aran ------------------------------ Message: 12 Date: Tue, 24 Mar 2009 20:28:30 -0700 From: Andreas Raab <andreas.raab at gmx.de> Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <49C9A4DE.4030801 at gmx.de> Content-Type: text/plain; charset=ISO-2022-JP Aran Lunzer wrote: > So it seems that something has changed in the VMs, and that something in > the DLL only works with new ones. But given that Balasz said that they > had used ProcessWrapper with 3.7, I wondered whether they had - or could > recompile - a version of the DLL that would be compatible with an old VM. > > What has changed in the VM wrt DLL loading? Something to do with > 64/32-bit support, perhaps? I don't recall. But you should be able to recompile the plugin for the version you need it to work with unless it uses any of the newer features. There are two ways to do that: a) Grab the source for the original 3.7 build, put the plugin into the proper place and build it against the 3.7 sources. b) Use your current build environment and #define VM_PROXY_MINOR to be the minimum version you can get away with (i.e., the minimum version the plugin compiles with). Both should work. Cheers, - Andreas ------------------------------ Message: 13 Date: Wed, 25 Mar 2009 05:27:35 +0100 From: "Klaus D. Witzel" <klaus.witzel at cobss.com> Subject: [squeak-dev] Re: [bug] xor: is this an old bug or what? To: squeak-dev at lists.squeakfoundation.org Message-ID: <op.urbyn9pxrf0v61 at toshiba19> Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii On Tue, 24 Mar 2009 23:01:45 +0100, Eliot Miranda wrote: > On Tue, Mar 24, 2009 at 1:36 PM, Randal L. Schwartz wrote: > >> >>>>> "Eliot" == Eliot Miranda <eliot.miranda at gmail.com> writes: >> >> Eliot> I think just >> >> True> xor: aBoolean >> Eliot> ^aBoolean not >> >> False> xor: aBoolean >> Eliot> ^aBoolean >> >> Eliot> and then leave subsequent usage to catch possible type errors; >> e.g. >> (false >> Eliot> xor: #blah) ifTrue: ... will raise a mustBeBoolean error. >> >> What I don't like about this is that the right operand doesn't get a >> chance >> to >> "boolify" itself, or define its own xor logic. The double-dispatch >> versions >> were a lot better at that. >> > If you want to do that you could implement it as > > False> xor: aBoolean > ^aBoolean not not This is, by Randal E. Bryant (who's using Shannon's expansion), equivalent to ^ aBoolean ifTrue: [true] ifFalse: [false] which the Squeak inlining compiler's magic + decompiler transforms to ^ aBoolean and: [true] When implemented in one of these two forms, a comment can explain that it's a not not implementation. > but I'd argue that isn't necessary. The old code didn't type check and > we've lived with it for a loooong time. I think that Randal makes the point; especially when the result is stored for later. The other boolean messages do implicit (by the inlining compiler) check their argument for #isBoolean, that's what should be done by #xor: as well. > But in any case, the not is a form of double-dispatch. It just points > out > that one can use not instead of xorTrue and is more comprehensible > because "not" is familiar. > >> >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 >> 0095 >> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside >> discussion -- "If at first, the idea is not absurd, then there is no hope for it". Albert Einstein ------------------------------ Message: 14 Date: Tue, 24 Mar 2009 23:08:58 -0700 (PDT) From: Jerome Peace <peace_the_dreamer at yahoo.com> Subject: [squeak-dev] How to tell if you have a boolean when you care to know To: squeak-dev at lists.squeakfoundation.org Message-ID: <323844.44780.qm at web50306.mail.re2.yahoo.com> Content-Type: text/plain; charset=us-ascii In another tread Keith Hodges wrote: 2009/3/24 Keith Hodges <keith_hodges at yahoo.co.uk> > true xor: [ true ] => true > > discuss > > Keith a simple guard for a boolean can be written simply. true xor: bar aBoolean will throw an error when bar is not a boolean if Boolean>>aBoolean ^self and all other classes agree not to implement aBoolean, This pattern can be extended to do all sorts of dynamic type checking. Keith: Great bug find says Puck. Elliot: +1 for your proposed fix for #xor: Yours in curiosity and service, --Jerome Peace and his imaginative friend Puck, fearless bug finder and Trouble Maker. ------------------------------ Message: 15 Date: Wed, 25 Mar 2009 15:38:35 +0900 (JST) From: "Aran Lunzer" <aran at meme.hokudai.ac.jp> Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] To: squeak-dev at lists.squeakfoundation.org Message-ID: <c538a89018a5da2cb5f7c83d78ec7387.squirrel at km.meme.hokudai.ac.jp> Content-Type: text/plain;charset=iso-2022-jp Andreas Raab wrote: > Aran Lunzer wrote: >> So it seems that something has changed in the VMs, and that something in >> the DLL only works with new ones. But given that Balasz said that they >> had used ProcessWrapper with 3.7, I wondered whether they had - or could >> recompile - a version of the DLL that would be compatible with an old >> VM. >> >> What has changed in the VM wrt DLL loading? Something to do with >> 64/32-bit support, perhaps? > > I don't recall. But you should be able to recompile the plugin for the > version you need it to work with unless it uses any of the newer > features. There are two ways to do that: > > a) Grab the source for the original 3.7 build, put the plugin into the > proper place and build it against the 3.7 sources. > > b) Use your current build environment and #define VM_PROXY_MINOR to be > the minimum version you can get away with (i.e., the minimum version the > plugin compiles with). Wow! Approach (b) did the trick! I only needed to increment by 1. Sneaky but effective :-) Many thanks - Aran ------------------------------ Message: 16 Date: Tue, 24 Mar 2009 23:44:58 -0700 From: Andreas Raab <andreas.raab at gmx.de> Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <49C9D2EA.30104 at gmx.de> Content-Type: text/plain; charset=ISO-2022-JP Aran Lunzer wrote: >> b) Use your current build environment and #define VM_PROXY_MINOR to be >> the minimum version you can get away with (i.e., the minimum version the >> plugin compiles with). > > Wow! Approach (b) did the trick! I only needed to increment by 1. > > Sneaky but effective :-) Not sneaky at all. The interface is designed in such a way that you can compile for older proxy versions if you'd like to. Cheers, - Andreas ------------------------------ Message: 17 Date: Wed, 25 Mar 2009 16:34:05 +0900 (JST) From: "Aran Lunzer" <aran at meme.hokudai.ac.jp> Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] To: squeak-dev at lists.squeakfoundation.org Message-ID: <9545d67826a9f90b4cb42384691eae21.squirrel at km.meme.hokudai.ac.jp> Content-Type: text/plain;charset=iso-2022-jp Andreas Raab wrote: >>> b) Use your current build environment and #define VM_PROXY_MINOR to be >>> the minimum version you can get away with (i.e., the minimum version >>> the plugin compiles with). >> >> Wow! Approach (b) did the trick! I only needed to increment by 1. >> >> Sneaky but effective :-) > > Not sneaky at all. The interface is designed in such a way that you can > compile for older proxy versions if you'd like to. Hmmm... I see what you're saying. But I only recompiled the VM, pretending that it has a minor-version of 6 when in fact it only includes the changes up to 5. That's surely sneaky, in general... though in this case I have the source code of the newest VM and of the plugin, and a quick look suggests no major code-breaking changes between 5 and 6. And the test cases all run, so something must be happy. Thanks again Aran ------------------------------ Message: 18 Date: Wed, 25 Mar 2009 08:54:52 +0000 From: Simon Kirk <simon.kirk at pinesoft.co.uk> Subject: Re: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <D13134A6-59D5-49AE-8416-3558EBBE2FBF at pinesoft.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi There. I see from this message that you're working in the .NET bridge. I did a fair amount of work with this myself a year or two ago as a potential means to migrate some of our legacy VB6 stuff via COM interop so that we could use Squeak for our new software. However, I had significant issues with load testing. When I started hitting the system with many processes the bridge would catastrophically fail due to limitations in the Windows TCP/IP stack: I'm sure you're aware that Windows has a built-in limit on the number of allowed open Sockets: I would quite easily hit this limit if I pushed hard enough, as the architecture of the bridge didn't clean up quickly enough for dead Squeak processes (this may really be a limitation in Squeak rather than the bridge, but the reliance on TCP/ IP communication between the two effectively means the same thing). I had planned to try removing the use of sockets entirely and moving to something more scalable, but in the end the use case evaporated. But I'd still love to know if you have progressed the bridge in a way that means you no longer get problems like the one I have described above. I'd also be willing to share any of the work I did in case it might help you, if I can find it. Regards, Simon On 25 Mar 2009, at 03:20, Aran Lunzer wrote: > Andreas wrote: >> Aran Lunzer wrote: >>> Looking at the source code for the DLL, I'm afraid that at the >>> level of my >>> non-Squeak skills it would probably take me a day to rebuild it. >>> Do you >>> happen to have a 3.7-specific compiled DLL? >> >> It is extremely unlikely that the problem is with the DLL. More >> likely >> you are switching between VMs that are not compatible with this >> version. >> Try running your 3.7 images with a more recent VM and see if this >> works >> with the DLL in question. > > Back in my original message about OSProcess I mentioned that I'm > working > with a 3.7 Web-browser-plugin VM that has been customised (to do > various > things in support of the .NET bridge). If I can't persuade > ProcessWrapper > to work with that, I can't use it. At least, not this year :-) > > I did a little more testing and, as you suggested, the more recent VM > helped: the out-of-the-box 3.8 release (6665), for example, couldn't > load > the ProcessWrapper DLL with its standard VM (Nov 2003), but could > when I > wheeled in the VM from 3.9. > > So it seems that something has changed in the VMs, and that > something in > the DLL only works with new ones. But given that Balasz said that > they > had used ProcessWrapper with 3.7, I wondered whether they had - or > could > recompile - a version of the DLL that would be compatible with an > old VM. > > What has changed in the VM wrt DLL loading? Something to do with > 64/32-bit support, perhaps? > > > All the best - > > Aran > > > > Consider your responsibility to the environment - think before you print! ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA ------------------------------ Message: 19 Date: Wed, 25 Mar 2009 11:05:54 +0000 From: Keith Hodges <keith_hodges at yahoo.co.uk> Subject: [squeak-dev] Re: Newbie Questions To: magma at lists.squeakfoundation.org, Pharo-project at lists.gforge.inria.fr, The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <49CA1012.30806 at yahoo.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Cross posted because I think others may find this discussion useful: Chris Muller wrote: > Hi Keith, I think the work you did on Level-Playing Field and MC 1.5 > has always sounded fantastic. > >> implemented it. Magma users use a variety of images and Magma needs you >> to have MCConfigurations working. Thats what LevelPlayingField in LPF >> gives you. >> > > So if it makes MC Configurations "work" why do *I* need to use it and > not just those wanting to load Magma via MC Configurations? > > You dont, but I kind of assume that you are a user too. >> Also the issue of extensions to classes that don't exist in older images >> is solved via the orphanage. MC1.5 doesnt complain like MC1 does. >> > > This is again something that happens for those *loading* Magma, so is > there a reason it is needed by the person doing the deployment? And, > if so, and I do, will others who want to load it require MC 1.5 and/or > LPF? > > The reason I have not moved on it after all this time, and I'm almost > ashamed to say it, it has never bubbled up into the realm of > critical-need that exceeded other priorities. Is LPF and MC 1.5 "drop > in and go?", completely compatible with existing mc packages? > > Thanks.. > Chris > It should be more so. The original MC1 made no effort to make anything compatible with anything else. It uses a simple binary storeOn: so save its binary data. This means that if you add an instance variable to any class in MC1's model, your packages are incompatible with past MC1's This is what happened, the MC in 3.9 added support for traits, and so packages saved, with that MC are incompatible with previous MC's. MC1.5 knows about this, and if a model class is realised with have extra data items, that it does not have inst vars for, it pops them into a properties dictionary. Also, MC1.5 makes an effort to only save the minimum amounts of instVars, so if your class does not have any Traits it saves, only the non-trait oriented inst-vars, and in doing so in theory the packages it generates should be compatible with even the older non 3.9 MC's. The original MC1 was very naive about handling errors. It would simply retry anything that raised an error. There were a number of situations that it did not handle well, such as renaming or re-ordering of inst vars. MC1.5 takes a much more considered approach. It attempts to actually make the class definition compatible with both the before and after situations, when loading methods. Obviously this is not always possible. In theory MC1.5 should handle more of the difficult cases, than MC1.0 did. However that doesn't stop people blaming MC1.5 if a package doesnt load, and they may find that the old MC1.0 can handle it using its old brute force approach. Finally MC1.6 with atomic loading is really cool, its over 3 times faster, which for something the size of Magma is a big deal. (However last time I tried it there was a minor bug) thanks for asking the relevant questions. Keith ------------------------------ Message: 20 Date: Wed, 25 Mar 2009 12:52:27 +0100 From: Bert Freudenberg <bert at freudenbergs.de> Subject: [squeak-dev] Monticello compatibility (was Re: Newbie Questions) To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> Message-ID: <17E817CE-3568-4F77-800E-4953BA6FCFE0 at freudenbergs.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On 25.03.2009, at 12:05, Keith Hodges wrote: > The original MC1 made no effort to make anything compatible with > anything else. It uses a simple binary storeOn: so save its binary > data. > This means that if you add an instance variable to any class in MC1's > model, your packages are incompatible with past MC1's This is what > happened, the MC in 3.9 added support for traits, and so packages > saved, > with that MC are incompatible with previous MC's. Well, actually, in MC1 the binary snapshot was nothing than a speed optimization. It stored the source code as text, too. If the binary snapshot loading failed, it fell back to parsing the source. Has this changed? > MC1.5 knows about this, and if a model class is realised with have > extra > data items, that it does not have inst vars for, it pops them into a > properties dictionary. Also, MC1.5 makes an effort to only save the > minimum amounts of instVars, so if your class does not have any Traits > it saves, only the non-trait oriented inst-vars, and in doing so in > theory the packages it generates should be compatible with even the > older non 3.9 MC's. > > The original MC1 was very naive about handling errors. It would simply > retry anything that raised an error. There were a number of situations > that it did not handle well, such as renaming or re-ordering of inst > vars. Indeed. Or annoying issues like not sorting class vars leading to spurious conflicts. > MC1.5 takes a much more considered approach. It attempts to actually > make the class definition compatible with both the before and after > situations, when loading methods. Obviously this is not always > possible. > > In theory MC1.5 should handle more of the difficult cases, than MC1.0 > did. However that doesn't stop people blaming MC1.5 if a package > doesnt > load, and they may find that the old MC1.0 can handle it using its old > brute force approach. > > Finally MC1.6 with atomic loading is really cool, its over 3 times > faster, which for something the size of Magma is a big deal. (However > last time I tried it there was a minor bug) Sounds rather nice. Wish I could spend more time playing with it. I have a question though: How does the Installer-based 3.11 development style go together with Monticello packages? Wouldn't every bug fix installed per changeset from Mantis make the packages dirty? - Bert - ------------------------------ _______________________________________________ Squeak-dev mailing list Squeak-dev at lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev End of Squeak-dev Digest, Vol 75, Issue 43 ******************************************
More information about the Squeak-dev mailing list |