- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3417 in pharo: BehaviorTest>>#testAllLocalCallsOn fails
by pharo＠googlecode.com Jan. 14, 2011

Jan. 14, 2011

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2 New issue 3417 by marcus.denker: BehaviorTest>>#testAllLocalCallsOn fails http://code.google.com/p/pharo/issues/detail?id=3417 BehaviorTest>>#testAllLocalCallsOn fails ... maybe because of MethodRereference is never equal to SourceMethodReference?

1 4

[Pharo-project] linux equivalent to monticello metacello...
by StÃ©phane Ducasse Jan. 14, 2011

Jan. 14, 2011

for the chapter on metacello I would like to have a table showing the equivalent between linux tools (if this is true) apt-get... and monticello/metacello can somebody point me to that ? Stef

5 4

[Pharo-project] [update 1.2] #12304
by StÃ©phane Ducasse Jan. 14, 2011

Jan. 14, 2011

12304 ----- - Theme tweaks from Igor.

1 0

[Pharo-project] ScrollBar needs a cleanup
by Igor Stasenko Jan. 14, 2011

Jan. 14, 2011

Class vars: UpArrow UpArrow8Bit UpArrow used in: initialize "ScrollBar initialize" UpArrow := Form extent: 6 @ 3 fromArray: #(805306368 2013265920 4227858432 ) offset: 0 @ 0. "" self initializeImagesCache upArrow8Bit "convert to 8-bit and convert white to transparent to avoid gratuitous conversion every time we put one in an ImageMorph" ^UpArrow8Bit ifNil: [ UpArrow8Bit := (ColorForm mappingWhiteToTransparentFrom: UpArrow) asFormOfDepth: 8 ] and UpArrow8Bit used just here: upArrow8Bit "convert to 8-bit and convert white to transparent to avoid gratuitous conversion every time we put one in an ImageMorph" ^UpArrow8Bit ifNil: [ UpArrow8Bit := (ColorForm mappingWhiteToTransparentFrom: UpArrow) asFormOfDepth: 8 ] and guess what? upArrow8Bit not used anywhere (there is no senders of it). That is really weird piece of code.. If there is an up arrow, then i expect to see down arrow, left and right as well.. but only up one... The cleanup in cs -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] How to bundle an application with icons?
by Dimitry Golubovsky Jan. 14, 2011

Jan. 14, 2011

OK, great. Thanks everybody who answered. The response from HernÃ¡n mentioning the createNewIconMethodsFromDirectory: method looks interesting. I'll try the other methods too. Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 1

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)
by mkobetic＠gmail.com Jan. 14, 2011

Jan. 14, 2011

OK, with two minor tweaks the socket streams started to behave better for me. The whole suite passes sometimes, although the results get often spoiled by transient failures which suggest a race condition in transform write stream. I think it's the the same one I occasionally see on VW side although it's quite rare there. But the fact that it comes up more frequently on Squeak side should help figuring it out, since it makes it more reproduceable. We'll see.

1 0

[Pharo-project] Hudson -> Jenkins
by Torsten Bergmann Jan. 13, 2011

Jan. 13, 2011

FYI: http://www.theregister.co.uk/2011/01/11/hudson_renamed_jenkins/ -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

2 1

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)
by mkobetic＠gmail.com Jan. 13, 2011

Jan. 13, 2011

Thanks everyone for your responses. I studied the ConnectionQueue that Wilhelm pointed me to, that didn't clarify things for me too much and I wasn't able to get it working either. Finally Sven's version of the script got me going again. I can already see the first problem in the Xtreams implementation in that it uses non-blocking read in Socket>>readInto:, simply changing it to the blocking read doesn't seem to fix things though. Quite the opposite. So now I'm trying to zero in on the exact API at the Socket level to use. To expand on the test script a bit more, this is what I'd like to get going: | input output listener process sync | sync := Semaphore new. listener := Socket newTCP. listener listenOn: 9999 backlogSize: 10. process := [ [ input := listener waitForAcceptFor: 10. sync signal ] ensure: [ listener close ] ] fork. output := Socket newTCP. output connectToHostNamed: 'localhost' port: 9999. sync wait. [ output sendData: 'Hello!'; close. input receiveData. ] ensure: [ output close. input close. process terminate ] Maybe I need some other calls in the last block, but I'm stuck even earlier again. When I interrupt the script above, the debugger highlights the whole last block (the ensure: receiver) and there's just the top level UndefinedObject>>DoIt context. Doesn't make much sense to me but debuggers have bugs as well. I'm guessing the process is stuck on the sync wait before that. But the sync semaphore has excess signals 1. And what is even stranger is that input is still nil. How is that possible ? Can someone get the above going ? I realize that I deviated from Sven's version by moving the read out of the accept process, but that shouldn't be a problem, or am I missing something ? I'm also wondering if there is a Socket test suite somewhere that already contains tests like the above, that I could mine for examples. I don't see any in the PharoCore1.2 image. Thanks, Martin "Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > | data input output listener socket1 socket2 process sync | > data := #uninitialized. > sync := Semaphore new. > listener := Socket newTCP. > listener listenOn: 9999 backlogSize: 10. > process := [ [ > socket1 := listener waitForAcceptFor: 10. > socket1 waitForDataFor: 10. > output := socket1 reading. > data := output rest. > sync signal ] ensure: [ listener close ] ] fork. > socket2 := Socket newTCP. > socket2 connectToHostNamed: 'localhost' port: 9999. > input := socket2 writing. > input write: 'Hello!'. > sync wait. > data asString > > Sven > > PS: Yes, Socket (and friends) have some pretty confusing API, you have to stick to what you know that works ;-) >

3 2

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)
by mkobetic＠gmail.com Jan. 13, 2011

Jan. 13, 2011

"Levente Uzonyi"<leves(a)elte.hu> wrote: > It works fine in my Squeak image. Using localhost may be a problem if your > local interface has an IPv6 address. Use 127.0.0.1 instead. Odd. The image I was using must have been corrupt somehow. When I took fresh Pharo 1.2 image the script worked fine. Thanks for the confirmation! Martin

1 0

Re: [Pharo-project] [squeak-dev] Xtreams up to date
by mkobetic＠gmail.com Jan. 13, 2011

Jan. 13, 2011

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > Thank you for all this work, this is a really interesting project, I am glad you are putting in the effort to bring this to Pharo/Squeak. Thanks. It's Nicolas who deserves the praise. I'm just trying to help out. > ... > I tried to look at one of the others XTFileReadingWritingTest>>#testWriteFromCollectionAt > > | data | > data := #[1 2 3 4 5 6 7]. > self assert: (self output write: 4 from: data at: 1) = 4. > self assert: (self input read: 4) = (data first: 4). > self assert: (self output write: 3 from: data at: 5) = 3. > self assert: (self input read: 3) = (data last: 3) > > The failure is at the last assertion. If I understand the code correctly, you write to a file in 2 steps (and yes the file contains the data). The input stream is created lazily, after the first write. But it seems strange to me to expect an open reading file stream to see newly written data ? Closing/reopening input works as expected. So you are also testing a particular OS feature here IMHO. Maybe this works on some OS's but it does not seem to work for me (Mac OS X, Cog VM), but other elements might be involved (caching/buffering at various levels, vm, primitives, ..). The intent of the test certainly is that the data would be visible. It's the same generic test we run across all the terminals. I can't give any authoritative statement whether it should work with files everywhere or not, but I can say that it does work across Linux, Windows and OSX in VW. I think the key aspect of this tests is that it's the same process doing the reading and writing. Actually maybe it's even that it must be the same descriptor. I'll have to take a closer look to see what's going on, but it seems to pass for me with Pharo (1.1.1 or 1.2, cog or standard VM) on Linux. I can test it on Windows as well, but I don't have OSX available for this. Does anyone know if it is reasonable to expect it to work on OSX ? I'm certainly not bent on keeping the test that way, our primary goal is to test the API on all terminals. But if it is meant to work this way even on files, then we probably should keep it that way.

1 0