October 2013 - Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 1 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

Oct. 21, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 2 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits Zinc.Tests.ZnServerTests.testEntityTooLarge

Oct. 21, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 1 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

Oct. 21, 2013

WhatsUp from: 2013-10-21 until: 2013-10-31

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2013-10-31 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Oct. 21, 2013

SuperCollider on Pharo [was: realtime]

by Paul Davidowitz

SqueakMap for OSC (http://map.squeak.org/sm/accountbyid/13fa7a75-1e76-471e-8f42-b676f4d8e373/p…) states: One can remote control supercollider and other sound generators implementing OSC using UDP. Release 2-1.1 - Now even runs with Supercollider! So, it looks like the work has already been done!

Oct. 20, 2013

Re: [Pharo-dev] ZnServerTests >> #testRequestLineTooLong

by btc＠openinworld.com

Oct. 20, 2013

Re: [Pharo-dev] SuperCollider on Pharo [was: realtime]

by StÃ©phane Ducasse

There is an OSC package on SmalltalkHub ;) On Oct 20, 2013, at 10:01 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > On Sun, Oct 20, 2013 at 11:29 AM, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: >> To: Dimitris Chloupis - >> >> Thanks for all the suggestions, and I see that the SuperCollider >> approach is apparently the best. >> How hard do you think is the effort to build the Pharo interface to the >> SuperCollider server? >> And as far as TDD test-writing, how does one test for sounds? >> I myself might be interested in writing the interface... >> >> It's interesting that the SuperCollider language is so Smalltalk-ish >> (more than Ruby)! >> If Supercollider is available on Pharo, then there is high chance that >> the SuperCollider >> community would become real Smalltalkers. > > I think this is a great idea. In fact SuperCollider software is > divided in two parts : a client (that used the SuperCollider language) > and the realtime sound synthesis server, who is language agnostic. You > just need to implement the protocol between the client and the server. > This protocol is based on OSC, that is already implemented in > Smalltalk. More information how it works here: > http://doc.sccode.org/Guides/ClientVsServer.html > > Recently, SuperCollider server has been update to a new > multi-processor version called SuperNova : > http://lac.linuxaudio.org/2011/download/tim_blechmann_supernova_slides.pdf > > Overtone is doing the same for Clojure: http://overtone.github.io/ > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

Oct. 20, 2013

Re: [Pharo-dev] SuperCollider on Pharo [was: realtime]

by Serge Stinckwich

On Sun, Oct 20, 2013 at 11:29 AM, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > To: Dimitris Chloupis - > > Thanks for all the suggestions, and I see that the SuperCollider > approach is apparently the best. > How hard do you think is the effort to build the Pharo interface to the > SuperCollider server? > And as far as TDD test-writing, how does one test for sounds? > I myself might be interested in writing the interface... > > It's interesting that the SuperCollider language is so Smalltalk-ish > (more than Ruby)! > If Supercollider is available on Pharo, then there is high chance that > the SuperCollider > community would become real Smalltalkers. I think this is a great idea. In fact SuperCollider software is divided in two parts : a client (that used the SuperCollider language) and the realtime sound synthesis server, who is language agnostic. You just need to implement the protocol between the client and the server. This protocol is based on OSC, that is already implemented in Smalltalk. More information how it works here: http://doc.sccode.org/Guides/ClientVsServer.html Recently, SuperCollider server has been update to a new multi-processor version called SuperNova : http://lac.linuxaudio.org/2011/download/tim_blechmann_supernova_slides.pdf Overtone is doing the same for Clojure: http://overtone.github.io/ Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Oct. 20, 2013

Re: [Pharo-dev] ZnServerTests >> #testRequestLineTooLong

by Sven Van Caekenberghe

Ben, Thanks for spending time looking into this. Now, you produced an enormous amount of information, but I am still confused. I have to come back to you when I have more time to rerun my older unfinished experiments using Windows 8.1 in VirtualBox, so that I can reformulate how I see things. Hopefully I will be able to understand what you were up to ;-) Sven On 20 Oct 2013, at 18:38, btc(a)openinworld.com wrote: > Sven, > > I've spent the day poking around in different parts of ZnServers and Sockets and got about as far as I can. I've reported a lot of stuff on the Case [1], and some expert review would now be useful - but you might want to skip to the end where I suggest a way that the problem might be invoked/simulated at your end on an otherwise working Max or Linux system. > > cheers -ben > > btc(a)openinworld.com wrote: >> While trying to debug this I found the error went away when I put a breakpoint to step through ZnMultiThreadedServer>>executeOneRequestResponseOn: >> Presuming a race condition I played with adding delays until I managed to isolate the following case... >> >> ZnMultiThreadedServer>>executeOneRequestResponseOn: stream >> | request response | >> (Delay forMilliseconds: 30) wait. "<----- <20 fails. >30 succeeds." >> (request := self readRequestSafely: stream) >> ifNil: [ ^ true ] >> ifNotNil: [ >> response := self handleRequest: request. >> self augmentResponse: response forRequest: request. >> self writeResponseSafely: response on: stream. >> response useConnection: stream. >> ]. >> ^ request wantsConnectionClose or: [ response wantsConnectionClose ] >> >> I've got more info coming, so I've raised ticket [1] to continue discussion. >> >> cheers -ben >> >> [1] https://pharo.fogbugz.com/default.asp?11960 >> >> Sven Van Caekenberghe wrote: >> > Ben, >> > >> > The goal of the test is to confirm that the server returns an error (refuses a request) when any line, in this case the first so called request line, it too long. Hence the artificially constructed URL. Of course, if you make it shorter, at one point it will be short enough so that it no longer fails - but that defeats the purpose of the test ;-) >> > >> > Now, the problem with this test and 3 other ones that are related, checking the reaction to other limits, is that they pass on Mac and Linux, but fail (randomly) on Windows, when ZdcSocketStream is used instead of SocketStream, currently the default. I have already looked into this, but up to now I failed to find the problem. The Socket class uses a number of primitives which have totally different implementations on the 3 platforms. >> > >> > Yes, I could use some help, but this is not easy. >> > >> > I also think there already is an issue for this, but I can't find it. >> > >> > Sven >> > >> > On 19 Oct 2013, at 18:54, btc(a)openinworld.com wrote: >> > >> > >> btc(a)openinworld.com wrote: >> >> >>> In the process of tying to review the slices for a few issues, I downloaded build #30500 Pharo3.0-win.zip from [1]. (Normally I use files.pharo.org but I wanted to ensure it was a "GREEN" build.) However before loading the slice to review I double-checked the baseline test results by running all tests from TestRunner. I had presumed all tests would be green but was surprised by some failures in the result. Well it maybe it has something to do with environment, but it would be nice for it to be clean to help isoalte any errors introduced by the slice under review. Before I log anything on Fogbugz in case someone can advise anything obvious, the Test Runner result is shown below [2]. >> >>> >> >>> My platform is 64-bit Windows 7 Home Premium Service Pack 1. >> >>> I'll try to follow up with more specific info on each line. >> >>> >> >>> cheers -ben >> >>> >> >>> [1] https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/566/ >> >>> >> >>> [2] FAILURE ZnServerTests >> #testRequestLineTooLong >> >>> >> I extracted #testRequestLineTooLong to something I can evaluate from Workspace... >> >> >> >> | numX url fudge | >> >> fudge := 0. >> >> numX := ZnConstants maximumLineLength - fudge . (url := ZnUrl fromString: 'http://localhost:1704/') >> >> addPathSegment: #echo; >> >> addPathSegment: (String new: numX withAll: $X). >> >> ZnClient new >> >> beOneShot; >> >> logToTranscript; >> >> url: url; >> >> get; >> >> response >> >> >> >> That fails with initial fudge factor of 0 - with 'ZnUnknownHttpVerion.' Here is the Transcript (including logging from ZnServer)... >> >> 2013-10-20 00:45:40 489094 D Executing request/response loop >> >> 2013-10-20 00:45:40 505527 I Wrote a ZnRequest(GET /echo/XXXXXXXX...XXXXX) >> >> 2013-10-20 00:45:40 505527 D Sent headers >> >> Accept: */* >> >> User-Agent: Zinc HTTP Components 1.0 >> >> Connection: close >> >> Host: localhost:1704 >> >> >> >> 2013-10-20 00:45:40 489094 D ZnLineTooLong bad request while parsing >> >> 2013-10-20 00:45:40 489094 I Wrote a ZnResponse(400 Bad Request text/plain;charset=utf-8 27B) >> >> 2013-10-20 00:45:40 489094 D Closing streamZnStatusLine >> >> >> >> With a fudge factor of 9 it still fails, but with 10 it succeeds. Interestingly, inspect 'url' shows... >> >> http://localhost:1704/echo/XXXXXXXXXXXXXXXXXXXXXXXXXX...etc >> >> ...and 10 characters = 1704/echo/ >> >> but then correlation does not equal cause. >> >> >> >> How should we proceed? >> >> >> >> cheers -ben >> >> >> >> > >> > >> > >> > >> > >

Oct. 20, 2013

Re: [Pharo-dev] [update 3.0] #30505

by phil＠highoctane.be

Cool. Diffs have this damn <historical> instead of the DateAndTime. Shouldn't we fix this? I thought it was done but it still looks there. Phil On Sun, Oct 20, 2013 at 9:36 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Finally :) > > Stef > > 30505 > ----- > > 11519 Merge Color and Translucent Color - post publication > https://pharo.fogbugz.com/f/cases/11519 > > 11951 Cannot access in text editors to temporaries in context inspectors. > Thanks Clement Bera > https://pharo.fogbugz.com/f/cases/11951 > > 11311 Rewrite Object class comment > https://pharo.fogbugz.com/f/cases/11311 > Diff information: > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-StephaneDucass… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-StephaneDucasse.1650.d… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Tests-StephaneDucass… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Primitives-StephaneD… > > >

Oct. 20, 2013