- Pharo-dev - lists.pharo.org

Re: [Pharo-project] seaside & pier on the iPhone

by Michael Roberts

Hi John, I would like to beta test your application. Mainly just to see it running and to understand Smalltalk on the iPhone and the beta testing mechanism. I'm not sure what information you need. My serial is: 889056XJY7K. If you need my UUID, how do I copy it from itunes or the phone? thanks Mike On Sun, Mar 22, 2009 at 4:57 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > For a couple of months now I have been working on a seaside/pier based > Wiki for the iPhone. > > I am now about a week away from sending it off to the Apple app store. > > However I'd like to broaden the beta test group a bit so I can catch > any issues before I submit it, especially in the area of persistency > storage. > > So what's it good for? I was asked that question this week, but let me > turn it around and ask: > > Good question what is Seaside and Pier good for? > > An iPhone Wiki? > Well... > > It's a handy construct for consolidating a bunch of PDF documents > since the mobile Safari Browser does a fine job of rendering them on > the device and a WIki does a fine job of providing a navigation > framework, but I'm sure there are other more important answers out > there somewhere? > > So > > Anyone who would like to participate as a beta tester can send me > email with a description of what they would use the Wiki for, and > supply their iPhone or iPod touch's device identifier and I'll look > into sending them a copy of the app. > > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 24, 2009

[Pharo-project] Fwd: [squeak-dev] Kernel fixes

by Michael Rueger

Hi all, haven't looked at it in detail so I don't know for example which "other changes" are needed, but I think we definitely should integrate the necessary fixes (if not done so already, hope I'm not proving myself ignorant here ;-)). Any takers? Michael ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: Tue, Mar 24, 2009 at 4:34 AM Subject: [squeak-dev] Kernel fixes To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Folks - While fixing Semaphore>>waitTimeoutMSecs: in our internal images, I noticed that 3.10 was still missing a number of important Kernel fixes that we've long taken for granted. If you run servers or rely otherwise on heavy process/delay/semaphore usage you will definitely want to apply the fixes provided at http://bugs.squeak.org/view.php?id=7321 To install, either download the patches or just execute: Â Â Â Â Installer mantis fixBug: 7321. Do note that these fixes apply only to 3.10 since they assume other changes to be present (so they won't work against 3.9 for example). Also, they depend on each other so unless you are really careful you should not pick and choose (this is why they are filed as a single bug). Cheers, Â - Andreas

March 24, 2009

Re: [Pharo-project] New Pharo-dev AND web based on 10259

by Serge Stinckwich

On Mon, Mar 23, 2009 at 10:08 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Here are pharo-dev and pharo-web based on latest 10259 before Closure: > http://code.google.com/p/pharo/wiki/Downloads?tm=2 Thank you Damien. ScriptLoader loadSuperOB. does not work in this image. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 24, 2009

Re: [Pharo-project] seaside & pier on the iPhone

by John M McIntosh

Web site goes live http://www.mobilewikiserver.com Still need a few more beta testers. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 24, 2009

Re: [Pharo-project] Unicode merge

by StÃ©phane Ducasse

Loaded without problems after I paste "Le volcan, qui culmine Ã 3.108 m, se trouve Ã 170 km au sud-ouest d'Anchorage, la plus grande agglomÃ©ration d'Alaska, dont les habitants ont jusqu'ici Ã©tÃ© Ã©pargnÃ©s par les projections. Les compagnies aÃ©riennes ont Ã©tÃ© invitÃ©es Ã contourner la zone." and got shortcut error. debug? code is nil in Unicode class>>value: on mac english keyboard, english OS. stef On Mar 23, 2009, at 4:40 PM, Michael Rueger wrote: > Hi all, > > in the process of merging the unicode work into the current system I > will upload a bunch of packages to the inbox. The packages will not > load > as they are, will need some config maps etc to load it all. > > I will let you know when I figured out a way how to load > everything :-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by Michael van der Gulik

On Mon, Mar 23, 2009 at 4:49 PM, Michael van der Gulik <mikevdg(a)gmail.com>wrote: > > > On Mon, Mar 23, 2009 at 2:21 PM, Michael van der Gulik <mikevdg(a)gmail.com>wrote: > >> >> >> On Mon, Mar 23, 2009 at 12:34 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> >>> Now consider the overhead of creating a fork vs the actual useful code >>> which is running within a block. >>> I presume, this code will run 10x times slower on a single core >>> processor, comparing to one w/o forks. >>> So, you will need to have 10 cores to match the computation time with >>> single core processor. >>> >>> I think its not wise to introduce parallelism on such low levels (in >>> Concurrent.Collections.Array>>withIndexDo:). Its like hammering nails >>> with microscope :) >>> >>> That's why i'm saying its too good to be true. >>> Introducing parallelism at such low levels will be a waste. I leaning >>> toward island model. This is a middle point between no sharing, like >>> in Hydra and sharing everything, like in what you proposing. >>> >> >> 10 times slower? Sounds like a made-up number to me... >> >> " Using 101 threads: " >> c := ConcurrentArray new: 1000001. >> Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i >> asString. ]]. >> 5711 >> 5626 >> 6074 >> >> " Using 11 threads: " >> c := ConcurrentArray new: 1000001. >> Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i >> asString. ]]. >> 3086 >> 3406 >> 3256 >> >> " Using 1 thread: " >> d := Array new: 1000001. >> Time millisecondsToRun: [d withIndexDo: [ :each :i | d at: i put: i >> asString]]. >> 2426 >> 2610 >> 2599 >> >> My implementation is 1/2 to 1/3 the speed of the single-threaded Array. If >> the blocks did more work, then the overhead would be lower and some benefit >> would be gained from using multiple cores. >> >> I don't have a good idea of where the overhead is going - maybe it's being >> lost in the block copying that is needed to work around Squeak's >> deficiencies? Or maybe it's waiting for the scheduler to do its stuff? >> >> Implementation attached, MIT license if you're picky. >> >> > I just tried it on VisualWorks as well. I removed the block copying and > renamed the method to "keysDo:" (I never thought of an array like that > before... keys and values). > > d := Array new: 1000001. > Time millisecondsToRun: [d keysDo: [ :i | d at: i put: i > printString]]. > 1180 > 982 > 1008 > > " Using 101 threads " > c := ConcurrentArray new: 1000001. > Time millisecondsToRun: [c keysDo: [ :i | c at: i put: i printString. > ]]. > 1072 > 1120 > 962 > > At this stage, I'm suspicous about the results :-). I tried it on SmalltalkMT on a dual-core system, but failed. I couldn't work out how to use its Semaphores; they don't behave like other Smalltalks and seem to be some MS Windows concoction. In fact, the whole environment feels like C++ with the Windows API. I also failed to get SmalltalkMT to use 100% of both cores on my machine despite forking lots of busy blocks. Huemul Smalltalk crashed when I tried to fork something. So... I remain saddened. It appears that Hydra and GemStone are the nearest we have to a multi-core Smalltalk, and they only do coarse-grained parallelism. This is a sad state of affairs. Gulik. -- http://gulik.pbwiki.com/

March 23, 2009

Re: [Pharo-project] Unicode merge

by Keith Hodges

Michael Rueger wrote: > Hi all, > > in the process of merging the unicode work into the current system I > will upload a bunch of packages to the inbox. The packages will not load > as they are, will need some config maps etc to load it all. > > I will let you know when I figured out a way how to load everything :-) > > Michael > atomic loading, just needs one tiny little bug fix (if you arent using traits) Keith

March 23, 2009

Re: [Pharo-project] Unicode merge

by StÃ©phane Ducasse

cool I will test that. I hope that we will not have traffic jam with the closure compiler. Stef On Mar 23, 2009, at 6:27 PM, Michael Rueger wrote: > Michael Rueger wrote: > >> I will let you know when I figured out a way how to load >> everything :-) > > OK, for early adopters :-) > > in the PharoInbox there are two slices that need to be loaded in order > into a current 10259 image: > > SLICE-UnicodeRwrite1-michael_rueger.1 > SLICE-UnicodeRewrite2.2.mcm (which is actually a config map). > > at least on my Windows system these load and withstand some quick > testing. > > Please test and let me know if it works on your platform and if not > (not > too unlikely ;-) ), which platform you are on and the debug log if > possible. > > On Linux you need to make sure to run the VM with the UTF-8 options > enabled. > > Thank you all for testing! > > Michael > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] [ANN] Closures for beta testers

by StÃ©phane Ducasse

I saw thanks. I hope to get some times continuing to explore the possible fixes. Stef On Mar 23, 2009, at 4:49 PM, Henrik Johansen wrote: > Done and done. > I'd rather not make a .cs for the > ClosureCompilerTest >>testInjectIntoDecompilations failure though, > as I neither feel comfortable messing around with Scanner, nor > particularily feel like it would be a good idea to change the test to > assume _ instead of := ... > > Cheers, > Henry > > StÃ©phane Ducasse wrote: >> excellent!!!! >> can you post cs to the Bugtracker so that >> we can reload all the fixes in a couple of click? >> >> http://code.google.com/p/pharo/issues/detail?id=685 >> >> I'm busy writing something else right now >> >> Stef >> On Mar 23, 2009, at 1:53 PM, Henrik Johansen wrote: >> >> >>> Here's a fix for the BlockContext test. >>> Basically, the error message had changed format, so the test that >>> the >>> correct error message was reported failed. >>> I changed the test to check for the (new) error format (which adds >>> argument(s) at the end of the sentence), and changed the error >>> message >>> to not call printstring, since this resulted in the string >>> containing >>> '1' instead of 1. >>> For some reason (which I'm not aware of) the printstring of numbers >>> seem >>> to include quotes. >>> >>> On a totally unrelated note, (didn't include it in the cs since it's >>> not >>> remotely related) >>> Debugger contents:notifying contains a call to Smalltalk>> isMorphic >>> which should probably be removed, comes up everytime you try to >>> save a >>> method edit in the debugger. >>> >>> Cheers, >>> Henry >>> >>> StÃ©phane Ducasse wrote: >>> >>>> I released an archive with two images >>>> 10259 with tests run >>>> 10259-withClosure + john + lukas + my fixes so far >>>> >>>> so that we can go faster to fix the problems >>>> >>>> https://gforge.inria.fr/frs/?group_id=1299 and files >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>>> >>> 'From Pharo0.1 of 16 May 2008 [Latest update: #10259] on 23 March >>> 2009 at 1:47:53 pm'! >>> >>> !BlockClosure methodsFor: 'error handing' stamp: 'Henrik Sperre >>> Johansen 3/23/2009 13:45'! >>> numArgsError: numArgsForInvocation >>> >>> | printNArgs | >>> printNArgs := [:n| n printString, ' argument', (n = 1 ifTrue: [''] >>> ifFalse:['s'])]. >>> self error: >>> 'This block accepts ', (printNArgs value: numArgs), >>> ', but was called with ', (printNArgs value: >>> numArgsForInvocation), '.'! ! >>> >>> >>> !BlockContextTest methodsFor: 'tests - evaluating' stamp: 'Henrik >>> Sperre Johansen 3/23/2009 13:45'! >>> testValueWithArguments >>> self >>> should: [aBlockContext >>> valueWithArguments: #(1 )] >>> raise: Error. >>> self >>> shouldnt: [aBlockContext >>> valueWithArguments: #()] >>> raise: Error. >>> [aBlockContext >>> valueWithArguments: #(1 )] >>> ifError: [:err :rcvr | self assert: err = 'Error: This block >>> accepts 0 arguments, but was called with 1 argument.']. >>> [[:i | 3 + 4] >>> valueWithArguments: #(1 2)] >>> ifError: [:err :rcvr | self assert: err = 'Error: This block >>> accepts 1 argument, but was called with 2 arguments.']! ! >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] Unicode merge

by Michael Rueger

Michael Rueger wrote: > I will let you know when I figured out a way how to load everything :-) OK, for early adopters :-) in the PharoInbox there are two slices that need to be loaded in order into a current 10259 image: SLICE-UnicodeRwrite1-michael_rueger.1 SLICE-UnicodeRewrite2.2.mcm (which is actually a config map). at least on my Windows system these load and withstand some quick testing. Please test and let me know if it works on your platform and if not (not too unlikely ;-) ), which platform you are on and the debug log if possible. On Linux you need to make sure to run the VM with the UTF-8 options enabled. Thank you all for testing! Michael

March 23, 2009