- Pharo-dev - lists.pharo.org

[Pharo-project] IMPORTANT BUGFIX IN SharedQueue>>#findFirst:

by Nicolas Cellier

Please load ASAP Collections-Sequenceable-nice.15 IMPORTANT BUG FIX IN SharedQueue>>findFirst: Otherwise you risk an infinite loop in high priority process... This happens randomly while running all tests Another change related to new InputEventSensor can also go in image immediatly: Kernel-nice.renggli.302 fixes missing InputEventSensor>>#flushNonKbdEvents Cheers

April 20, 2009

Re: [Pharo-project] Lots of characters lost while typing in Unix

by Igor Stasenko

2009/4/20 Michael Roberts <mike(a)mjr104.co.uk>: > sorry to be pedantic but Michael's right. Â even if the second client > of the class is a test where you make an instance on the fly, assert a > few things and clean it up. Â You then have at least 2 instances. the > singleton and short-lived adhoc ones. Â systems with dependencies on > global state or behaviour are very hard to test. > Thanks, for argument! I'm also trying to be pedantic when proposing this. :) My point was, that its obviously an overkill to have a singleton<class> linked with singleton<instance> without strong evidences where multiple instances could be useful. > cheers, > > Mike > > On Mon, Apr 20, 2009 at 6:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> 2009/4/20 Michael Rueger <m.rueger(a)acm.org>: >>> Igor Stasenko wrote: >>>> Another thing, that i think it would be better is to not have an >>>> instance side methods. >>>> Since we never need a multiple instances of InputEventFetcher in >>>> system, then instead of singleton scheme, it would be better to move >>>> all methods and ivars to class side - simply because a class is >>>> already singleton. >>>> This will help to avoid discrepancies, like we just met. >>> >>> -10000 >>> >>> Using singleton instances is a proven design pattern. >>> And, you never know if you won't need more than one input fetcher ;-) >>> >> Clearly, this is not the case, because your code hosted on a single VM >> ;) and its the only source of events for fetcher. >> >>> Michael >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

April 20, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by Nicolas Cellier

Wait, I think the problem is not at all caused by Concurrency fixes... I strongly suspect introduction of SharedQueue>>#findFirst: The test hang randomly in: InputEventSensor>>peekKeyboardEvent "Allows for use of old Sensor protocol to get at the keyboard, as when running kbdTest or the InterpreterSimulator in Morphic" ^eventQueue findFirst: [:buf | self isKbdEvent: buf] Old code was: peekKeyboardEvent "Return the next keyboard char event from the receiver or nil if none available" ^eventQueue nextOrNilSuchThat: [:buf | buf first = EventTypeKeyboard and: [(buf fourth) = EventKeyChar]] But I noticed SharedQueue>>findFirst: and SharedQueue>>nextOrNilSuchThat: are not EXACTLY the same... findFirst: FAILS TO INCREMENT readPos... Nicolas 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I know that john has a vm with traces but I do not know how to do what > you need. > Do you think that it can help if I integrate the next batch? > Nicolas I can also remove from the stream the item so that you can > take time to look at it. > you just need to load the version 836 of the scriptLoader (from the > pharo repository). > and manually launch the loading of the last update. > > ScriptLoader new update10287 > > Stef > > On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote: > >> Do you know how to dump Smalltalk process stacks from within the VM >> debugger (I mean gdb) ? >> >> 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> But the tests just blocked after 2256 run, 2162 passes, etc... >>> and no response to ALT+. :( >>> >>> I will have a quick look... >>> >>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> Ok now I understand why I only got 14 and not 16 tests green. >>>> >>>> >>>> On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote: >>>> >>>>> Yes, it seems OK >>>>> The tests are running on my linux versions now... not yet frozen >>>>> The two additionnal DelayTest from Andreas which were in >>>>> KernelTests-nice.95.mcz are not yet loaded but will be with >>>>> KernelTests-nice.96.mcz >>>>> >>>>> Nicolas >>>>> >>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> it is not a problem. >>>>>> I just want to make sure. Some changes are easy to undo some not. >>>>>> So I will integrate the second batch. >>>>>> Did you have a look at the integration I just did. >>>>>> >>>>>> Stef >>>>>> >>>>>> On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote: >>>>>> >>>>>>> Yes, >>>>>>> Kernel-nice.renggli.301.mcz simply remove the upper limit for >>>>>>> Delay >>>>>>> because Andreas changes solved the problem. >>>>>>> KernelTests-nice.96.mcz change the Delay upper bound test >>>>>>> System-Support-nice.11.mcz fix a problem of sending deprecated >>>>>>> Process>>#offList (it should have gone with earlier change) >>>>>>> >>>>>>> I wanted to decompose integration of Andreas changes carefully >>>>>>> to be >>>>>>> sure it can be redone... >>>>>>> But now, I realize that I published too many messages, that's >>>>>>> confusing >>>>>>> >>>>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>>> >>>>>>>> nicolas >>>>>>>> >>>>>>>> I integrated in 10287 >>>>>>>> >>>>>>>>>> script363 >>>>>>>>>> Delay startTimerEventLoop. >>>>>>>>>> (self buildConfigurationMapFor: >>>>>>>>>> #('Kernel-nice.renggli.300.mcz')) load >>>>>>>> >>>>>>>> So I imagine that the following one is another fix that I should >>>>>>>> integrate. >>>>>>>> Is is correct >>>>>>>> >>>>>>>>> Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel >>>>>>>>> concurrency fixes? 3.10 >>>>>>>>> http://code.google.com/p/pharo/issues/detail?id=688 >>>>>>>>> >>>>>>>>> I published the changes in PharoInbox >>>>>>>>> I checked that entire changes related to mantis 7321 list can >>>>>>>>> be >>>>>>>>> loaded with following instructions: >>>>>>>>> >>>>>>>>> Delay startTimerEventLoop. >>>>>>>>> (ScriptLoader new buildConfigurationMapFor: >>>>>>>>> #('Kernel-nice.renggli.301.mcz' >>>>>>>>> 'KernelTests-nice.96.mcz' >>>>>>>>> 'System-Support-nice.11.mcz')) load. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are listed in the owner >>>>>>>>> or CC fields of this issue, or because you starred this issue. >>>>>>>>> You may adjust your issue notification preferences at: >>>>>>>>> http://code.google.com/hosting/settings >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 20, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by Michael Roberts

just to say that the tests freeze around 10284cl. I was going to mention it but it already came up! Do we run all the tests before pushing out updates? 10281cl ran through ok. thanks, Mike

April 20, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by StÃ©phane Ducasse

I know that john has a vm with traces but I do not know how to do what you need. Do you think that it can help if I integrate the next batch? Nicolas I can also remove from the stream the item so that you can take time to look at it. you just need to load the version 836 of the scriptLoader (from the pharo repository). and manually launch the loading of the last update. ScriptLoader new update10287 Stef On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote: > Do you know how to dump Smalltalk process stacks from within the VM > debugger (I mean gdb) ? > > 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> But the tests just blocked after 2256 run, 2162 passes, etc... >> and no response to ALT+. :( >> >> I will have a quick look... >> >> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Ok now I understand why I only got 14 and not 16 tests green. >>> >>> >>> On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote: >>> >>>> Yes, it seems OK >>>> The tests are running on my linux versions now... not yet frozen >>>> The two additionnal DelayTest from Andreas which were in >>>> KernelTests-nice.95.mcz are not yet loaded but will be with >>>> KernelTests-nice.96.mcz >>>> >>>> Nicolas >>>> >>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> it is not a problem. >>>>> I just want to make sure. Some changes are easy to undo some not. >>>>> So I will integrate the second batch. >>>>> Did you have a look at the integration I just did. >>>>> >>>>> Stef >>>>> >>>>> On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote: >>>>> >>>>>> Yes, >>>>>> Kernel-nice.renggli.301.mcz simply remove the upper limit for >>>>>> Delay >>>>>> because Andreas changes solved the problem. >>>>>> KernelTests-nice.96.mcz change the Delay upper bound test >>>>>> System-Support-nice.11.mcz fix a problem of sending deprecated >>>>>> Process>>#offList (it should have gone with earlier change) >>>>>> >>>>>> I wanted to decompose integration of Andreas changes carefully >>>>>> to be >>>>>> sure it can be redone... >>>>>> But now, I realize that I published too many messages, that's >>>>>> confusing >>>>>> >>>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>> >>>>>>> nicolas >>>>>>> >>>>>>> I integrated in 10287 >>>>>>> >>>>>>>>> script363 >>>>>>>>> Delay startTimerEventLoop. >>>>>>>>> (self buildConfigurationMapFor: >>>>>>>>> #('Kernel-nice.renggli.300.mcz')) load >>>>>>> >>>>>>> So I imagine that the following one is another fix that I should >>>>>>> integrate. >>>>>>> Is is correct >>>>>>> >>>>>>>> Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel >>>>>>>> concurrency fixes? 3.10 >>>>>>>> http://code.google.com/p/pharo/issues/detail?id=688 >>>>>>>> >>>>>>>> I published the changes in PharoInbox >>>>>>>> I checked that entire changes related to mantis 7321 list can >>>>>>>> be >>>>>>>> loaded with following instructions: >>>>>>>> >>>>>>>> Delay startTimerEventLoop. >>>>>>>> (ScriptLoader new buildConfigurationMapFor: >>>>>>>> #('Kernel-nice.renggli.301.mcz' >>>>>>>> 'KernelTests-nice.96.mcz' >>>>>>>> 'System-Support-nice.11.mcz')) load. >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are listed in the owner >>>>>>>> or CC fields of this issue, or because you starred this issue. >>>>>>>> You may adjust your issue notification preferences at: >>>>>>>> http://code.google.com/hosting/settings >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >

April 20, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by Nicolas Cellier

2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Do you know how to dump Smalltalk process stacks from within the VM > debugger (I mean gdb) ? > never mind, found it: (gdb) info functions .*[Ss]tack.* All functions matching regular expression ".*[Ss]tack.*": File gnu-interp.c: sqInt balancedStackafterPrimitivewithArgs(sqInt, sqInt, sqInt); sqInt fetchStackPointerOf(sqInt); sqInt okayActiveProcessStack(void); sqInt popStack(void); sqInt primitiveInstVarsPutFromStack(void); sqInt primitiveStoreStackp(void); sqInt printAllStacks(void); etc... (gdb) call printAllStacks() Process 2022647440 SharedQueue>findFirst: 2022647348 Semaphore>critical: 2022647256 BlockClosure>ensure: 2022647100 Semaphore>critical: 2022646948 SharedQueue>findFirst: 2022646856 InputEventSensor>peekKeyboardEvent 2022646764 InputEventSensor>keyboardPressed 2022646672 InputEventSensor>flushKeyboard 2022646580 Debugger>openNotifierContents:label: 2022646248 >openInterrupt:onProcess: 2022645324 DebuggerUnwindBug>testUnwindDebugger 2022645232 TestCase>performTest 2022645140 TestCase>runCase 2022645048 BlockClosure>ensure: 2022644916 TestCase>runCase 2022644824 TestResult>runCase: 2022644704 BlockClosure>on:do: 2022644560 TestResult>runCase: 2022644468 BlockClosure>on:do: 2022644340 TestResult>runCase: 2022644248 TestCase>run: 2022644156 TestRunner>runTest: 2022644064 TestRunner>runSuite: 2022643972 SequenceableCollection>do:displayingProgress: 2015446772 SequenceableCollection>withIndexDo: 2015446652 SequenceableCollection>do:displayingProgress: 2015446560 ProgressInitiationException>defaultAction 2015446384 BlockClosure>ensure: 2015446100 ProgressInitiationException>defaultAction 2015446008 UndefinedObject>handleSignal: 2015445916 ContextPart>handleSignal: 2015445824 Exception>signal 2015445684 ProgressInitiationException>display:at:from:to:during: 2015445592 >display:at:from:to:during: 2015445464 String>displayProgressAt:from:to:during: 2015445276 SequenceableCollection>do:displayingProgress: 2015445184 TestRunner>basicRunSuite:do: 2015445092 BlockClosure>ensure: 2015441744 TestRunner>basicRunSuite:do: 2015441652 TestRunner>runSuite: 2015348260 TestRunner>runAll 2015348168 PluggableButtonMorph>performAction 2015348052 PluggableButtonMorphPlus>performAction 2015347960 PluggableButtonMorph>mouseUp: 2015347868 SequenceableCollection>do: 2015344832 PluggableButtonMorph>mouseUp: 2015344696 PluggableButtonMorphPlus>mouseUp: 2015344604 Morph>handleMouseUp: 2015344512 MouseButtonEvent>sentTo: 2015344420 Morph>handleEvent: 2015344328 Morph>handleFocusEvent: 2015344148 HandMorph>sendFocusEvent:to:clear: 2015344056 PasteUpMorph>becomeActiveDuring: 2015343964 BlockClosure>on:do: 2015343872 PasteUpMorph>becomeActiveDuring: 2015343752 HandMorph>sendFocusEvent:to:clear: 2015343660 HandMorph>sendEvent:focus:clear: 2015343568 HandMorph>sendMouseEvent: 2015343420 HandMorph>handleEvent: 2015343268 HandMorph>processEvents 2015343156 WorldState>doOneCycleNowFor: 2015343064 SequenceableCollection>do: 2015342972 WorldState>handsDo: 2015342880 WorldState>doOneCycleNowFor: 2015342752 WorldState>doOneCycleFor: 2015342660 PasteUpMorph>doOneCycle 2008850980 >spawnNewProcess 2008850852 BlockClosure>newProcess Process 2010748656 >finalizationProcess 2010748564 >restartFinalizationProcess 2010748748 BlockClosure>newProcess Process 2022648416 Semaphore>critical: 2022648324 BlockClosure>ensure: 2022648168 Semaphore>critical: 2022648052 SharedQueue>nextPut: 2022647960 InputEventSensor>queueEvent: 2022647832 InputEventSensor>handleEvent: 2022647740 InputEventFetcher>signalEvent: 2022647624 OrderedCollection>do: 2022647532 InputEventFetcher>signalEvent: 2010762944 InputEventFetcher>eventLoop 2010762852 InputEventPollingFetcher>installEventLoop 2010763076 BlockClosure>newProcess Process 2022648508 >handleTimerEvent 2011103312 >? 2011103156 BlockClosure>on:do: 2011103064 >? 2011102972 >? 2011103464 BlockClosure>newProcess Process 2015023020 SystemDictionary>lowSpaceWatcher 2015022928 SystemDictionary>installLowSpaceWatcher 2015023152 BlockClosure>newProcess Process 2022646156 DebuggerUnwindBug>testUnwindDebugger 2022645848 Semaphore>critical: 2022645756 BlockClosure>ensure: 2022645664 Semaphore>critical: 2022645572 DebuggerUnwindBug>testUnwindDebugger 2022645940 BlockClosure>newProcess

April 20, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by StÃ©phane Ducasse

Arg so you confirmed my fear. Stef On Apr 20, 2009, at 10:10 PM, Nicolas Cellier wrote: > But the tests just blocked after 2256 run, 2162 passes, etc... > and no response to ALT+. :( > > I will have a quick look... > > 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Ok now I understand why I only got 14 and not 16 tests green. >> >> >> On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote: >> >>> Yes, it seems OK >>> The tests are running on my linux versions now... not yet frozen >>> The two additionnal DelayTest from Andreas which were in >>> KernelTests-nice.95.mcz are not yet loaded but will be with >>> KernelTests-nice.96.mcz >>> >>> Nicolas >>> >>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> it is not a problem. >>>> I just want to make sure. Some changes are easy to undo some not. >>>> So I will integrate the second batch. >>>> Did you have a look at the integration I just did. >>>> >>>> Stef >>>> >>>> On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote: >>>> >>>>> Yes, >>>>> Kernel-nice.renggli.301.mcz simply remove the upper limit for >>>>> Delay >>>>> because Andreas changes solved the problem. >>>>> KernelTests-nice.96.mcz change the Delay upper bound test >>>>> System-Support-nice.11.mcz fix a problem of sending deprecated >>>>> Process>>#offList (it should have gone with earlier change) >>>>> >>>>> I wanted to decompose integration of Andreas changes carefully >>>>> to be >>>>> sure it can be redone... >>>>> But now, I realize that I published too many messages, that's >>>>> confusing >>>>> >>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> >>>>>> nicolas >>>>>> >>>>>> I integrated in 10287 >>>>>> >>>>>>>> script363 >>>>>>>> Delay startTimerEventLoop. >>>>>>>> (self buildConfigurationMapFor: >>>>>>>> #('Kernel-nice.renggli.300.mcz')) load >>>>>> >>>>>> So I imagine that the following one is another fix that I should >>>>>> integrate. >>>>>> Is is correct >>>>>> >>>>>>> Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel >>>>>>> concurrency fixes? 3.10 >>>>>>> http://code.google.com/p/pharo/issues/detail?id=688 >>>>>>> >>>>>>> I published the changes in PharoInbox >>>>>>> I checked that entire changes related to mantis 7321 list can be >>>>>>> loaded with following instructions: >>>>>>> >>>>>>> Delay startTimerEventLoop. >>>>>>> (ScriptLoader new buildConfigurationMapFor: >>>>>>> #('Kernel-nice.renggli.301.mcz' >>>>>>> 'KernelTests-nice.96.mcz' >>>>>>> 'System-Support-nice.11.mcz')) load. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are listed in the owner >>>>>>> or CC fields of this issue, or because you starred this issue. >>>>>>> You may adjust your issue notification preferences at: >>>>>>> http://code.google.com/hosting/settings >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 >

April 20, 2009

[Pharo-project] [ANN] - SqueakDBX first stable version 1.0!!!

by Mariano Martinez Peck

Hi folks: After a continuous work since January 08, we are very glad to announce our first stable version of SqueakDBX. For those who don't know what this is about, the aim of this project is to build an OpenDBX (http://www.linuxnetworks.de/doc/index.php/OpenDBX/) wrapper which will allow users to perform relational database operations ( DDL, DML and SQL) through a truly open source library. Through this feature, the squeak community will hopefully be able to interact with major database engines, such as Oracle and SQL Server, besides those which are open source, like PostgreSQL, MySQL or Sqlite. Moreover, by integrating this with GLORP ( http://www.glorp.org/) will allow us to generate a complete and open source solution to relational data base access. Why did we do squeakDBX? reeThere are several approaches to persistence in Squeak, some very interesting: OODB like Gemstone and magma, image, CouchDB or TokyoT/C, and so on. All of this options get sense if you can actually decide the way you will persist your objects. However, this is not something that happens very frequently. FREQUENTLY, the client (the one who pays you for making the software) requires you to use a particular persistence strategy (RDBMS). Not only that, but also a database in particular (like Oracle, MS SQL, and so on). They have lots of reasons: they already have license for it, they have support and companies for it, they know SQL, they want to do selects, legacy systems, and so on. But Squeak only provides drivers for MySQL and PostgreSQL natively, so... what would you do in the rest of the cases? move to another language? OK, we don't. We want to program systems in Squeak. If you know about SqueakDBX you can just see changelog here: http://wiki.squeak.org/squeak/6109; If you don't, you should continue reading ;) SqueakDBX features: -Cross-platform support: Linux, Windows (using MinGW) and Mac. See http://wiki.squeak.org/squeak/6108 -Runs on Squeak and Pharo. -Mini VM blocks when using FFI (asynchronous queries). See http://wiki.squeak.org/squeak/6060#External%20call%20implementation. -Own SqueakDBX plugin (experimental). Ability to easily change the external call strategy (FFI or our own plugin). -Support for: Oracle, PostgreSQL, MySQL, MS SQL Server, ODBC and SQLite3 -Transactional concept: begin transaction, commit and rollback. See http://wiki.squeak.org/squeak/6071 -Mappings from String to specific types in selects. See http://wiki.squeak.org/squeak/6075 -Special OpenDBX options: multistatements, ï»¿encryption, compression, paged results, MySQL modes, and more. See http://wiki.squeak.org/squeak/6068 -Automated database connection ralease (although manual disconnection is recommended ;-) -Automated results retrieving in order to do another query, after doing a query and not iterating ALL results -Lots of unit tests that buck up our project ;-) (85 right now). See http://wiki.squeak.org/squeak/6077. -Lots of benchmarks and comparison with native drivers (PostgreSQL and MySQL). See http://wiki.squeak.org/squeak/6063. -Error handling: Not only errors, but levels associated with an error in order to avoid FFI calls (if you get a fatal error, it has no sense to do another query and the resources must be free). See http://wiki.squeak.org/squeak/6076 -Query timeout (this is very useful for web applications) and page size can be set for each query. See http://wiki.squeak.org/squeak/6069 -Very completed documentation in wiki and getting started. -Code critics and SwaLint were run several times. -Good design (at least all the major refactors demonstrated that). Full documentation, installation and getting started instructions can be found at wiki page: http://wiki.squeak.org/squeak/6052 . We spent a lot of time in it. It has all the information you may need and is in continuosdevelopment. Benchmarks: We have a lot of SqueakDBX benchmarks and also some for native squeak drivers (PostgreSQL and MySQL) and SqueakDBX seems to be faster than both of them. You can read more here: http://wiki.squeak.org/squeak/6063 Packages can be installed from Universe (3.10) or SqueakMap. Current version is 1.0. Sources can be download from SqueakSource http://www.squeaksource .com/SqueakDBX (it requires FFI installed). OpenDBX version: 1.4. Remember that you can compile OpenDBX by yourself or use precompiledbinaries. For more information please read: http://wiki.squeak.org/squeak/6129. GLORP integration: Actually, this may include two parts: 1) The integration of GLORP with squeak is completely hardcoded with PostgreSQL native driver. Because of this, first we will do a refactor in GLORP in order to enable it to support different drivers. We will create a PostgreSQL driver with the things that GLORP already has. We invited Alan Night to have dinner with us when he came to Argentina. We told him our ideas and discuss for a while till we got a first design of this refactor. We have already started this part. 2) Create a SqueakDBX driver for GLORP just like the one we are planning to do for PostgreSQL. The last squeak port of GLORP is very old and there is nobody to do it. A friend of us, Diogenes Moreira, has accepted this job, so, thanks to him, we hope to have latest GLORP releases in Squeak. You can see our Glorp progress here: http://wiki.squeak.org/squeak/6132 Help is always wanted. We would really appreciate if you: -Give us opinions, comments, ideas, new features, complaints and so on. -Tell us if you find a bug. -Tell us if you test SqueakDBX with other RDMBS or OS different from the ones we tested. Just to know if it works or not :) If you try SqueakDBX and you write something somewhere like a blog, let us know. We have this link: http://wiki.squeak.org/squeak/6131 where we put useful links for all the people. Special thanks to: -ESUG, for supporting us through Summer of Talk 08; -To Norbert (author of openDBX) for his help and to all the people who tested it and help us. Cheers, SqueakDBX team

April 20, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by Nicolas Cellier

Do you know how to dump Smalltalk process stacks from within the VM debugger (I mean gdb) ? 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > But the tests just blocked after 2256 run, 2162 passes, etc... > and no response to ALT+. :( > > I will have a quick look... > > 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Ok now I understand why I only got 14 and not 16 tests green. >> >> >> On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote: >> >>> Yes, it seems OK >>> The tests are running on my linux versions now... not yet frozen >>> The two additionnal DelayTest from Andreas which were in >>> KernelTests-nice.95.mcz are not yet loaded but will be with >>> KernelTests-nice.96.mcz >>> >>> Nicolas >>> >>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> it is not a problem. >>>> I just want to make sure. Some changes are easy to undo some not. >>>> So I will integrate the second batch. >>>> Did you have a look at the integration I just did. >>>> >>>> Stef >>>> >>>> On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote: >>>> >>>>> Yes, >>>>> Kernel-nice.renggli.301.mcz simply remove the upper limit for Delay >>>>> because Andreas changes solved the problem. >>>>> KernelTests-nice.96.mcz change the Delay upper bound test >>>>> System-Support-nice.11.mcz fix a problem of sending deprecated >>>>> Process>>#offList (it should have gone with earlier change) >>>>> >>>>> I wanted to decompose integration of Andreas changes carefully to be >>>>> sure it can be redone... >>>>> But now, I realize that I published too many messages, that's >>>>> confusing >>>>> >>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> >>>>>> nicolas >>>>>> >>>>>> I integrated in 10287 >>>>>> >>>>>>>> script363 >>>>>>>> Delay startTimerEventLoop. >>>>>>>> (self buildConfigurationMapFor: >>>>>>>> #('Kernel-nice.renggli.300.mcz')) load >>>>>> >>>>>> So I imagine that the following one is another fix that I should >>>>>> integrate. >>>>>> Is is correct >>>>>> >>>>>>> Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel >>>>>>> concurrency fixes? 3.10 >>>>>>> http://code.google.com/p/pharo/issues/detail?id=688 >>>>>>> >>>>>>> I published the changes in PharoInbox >>>>>>> I checked that entire changes related to mantis 7321 list can be >>>>>>> loaded with following instructions: >>>>>>> >>>>>>> Delay startTimerEventLoop. >>>>>>> (ScriptLoader new buildConfigurationMapFor: >>>>>>> #('Kernel-nice.renggli.301.mcz' >>>>>>> 'KernelTests-nice.96.mcz' >>>>>>> 'System-Support-nice.11.mcz')) load. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are listed in the owner >>>>>>> or CC fields of this issue, or because you starred this issue. >>>>>>> You may adjust your issue notification preferences at: >>>>>>> http://code.google.com/hosting/settings >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 >> >

April 20, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by Nicolas Cellier

No 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Nicolas for the integration of the second patch. > Is the Delay startTimerEventLoop mandatory? > > Stef > >>>>> >>>>> >>>>> >>>>>> Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel >>>>>> concurrency fixes? 3.10 >>>>>> http://code.google.com/p/pharo/issues/detail?id=688 >>>>>> >>>>>> I published the changes in PharoInbox >>>>>> I checked that entire changes related to mantis 7321 list can be >>>>>> loaded with following instructions: >>>>>> >>>>>> Delay startTimerEventLoop. >>>>>> (ScriptLoader new buildConfigurationMapFor: >>>>>> #('Kernel-nice.renggli.301.mcz' >>>>>> 'KernelTests-nice.96.mcz' >>>>>> 'System-Support-nice.11.mcz')) load. >>>>>> >>>>>> -- >>>>>> You received this message because you are listed in the owner >>>>>> or CC fields of this issue, or because you starred this issue. >>>>>> You may adjust your issue notification preferences at: >>>>>> http://code.google.com/hosting/settings >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> _______________________________________________ >> 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 >

April 20, 2009