June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZnClient send big data + progress

by Sven Van Caekenberghe

Hi Roberto, Let's see. First we start an HTTP server in Pharo 3: (ZnServer defaultOn: 1701) onRequestRespond: [ :request | request inspect. ZnResponse ok: (ZnEntity text: 'OK') ]; maximumEntitySize: 100*1024*1024; logToTranscript ; start. The handler code will always reply 'OK', but also inspect the incoming request. I raise the maximum entity size to 100Mb. Here is a simple request: ZnClient new url: 'http://localhost:1701'; entity: (ZnEntity with: (0 to: 255) asByteArray); post. Next is a bigger one (10Mb): ZnClient new url: 'http://localhost:1701'; entity: (ZnEntity with: (ByteArray new: 10*1024*1023 withAll: 123)); post. Finally the big one (50Mb): ZnClient new url: 'http://localhost:1701'; timeout: 900; entity: (ZnEntity with: (ByteArray new: 50*1024*1023 withAll: 123)); post. That fails indeed, and I don't know why (yet). The weird thing is, it fails with only 6Mb written, always at the same position, while the 10Mb upload did work OK. Raising the timeout does indeed not make a difference. Data is written using 16Kb chunks, with progress notifications (see ZnUtils class>>#nextPutAll:on:). Luckily, there is a workaround, using the classic SocketStream somehow fixes the issue: ZnNetworkingUtils default socketStreamClass: SocketStream. Now, for the progress indication, Zinc certainly does it correctly, but somehow the UI does not always follow. You can verify this by writing to the Transcript: [ :bar | bar title: 'Uploading...'. [ ZnClient new signalProgress: true; url: 'http://localhost:1701'; entity: (ZnEntity with: (ByteArray new: 10*1024*1023 withAll: 123)); post ] on: HTTPProgress do: [ :progress | progress isEmpty ifFalse: [ bar current: progress percentage ]. Transcript crShow: progress. progress resume ] ] asJob run. Experiment with adding/commenting out the #crShow: you will see that it works, sometimes. HTH, Sven On 06 Jun 2014, at 10:47, roberto.minelli(a)usi.ch wrote: > Hi guys, > > I have a problem with Zinc, I need to send a huge amount of data (bytes) that translates to ~50Mb. > > When I do something like: > > ZnEasy > post: 'http://localhost:15432' > data: (ZnEntity bytes: aHugeByteArray.] > > I encounter a âConnectionTimedOut: Data send timed out.â, I attach the stack trace: > > ZdcSocketStream(ZdcSimpleSocketStream)>>flushBytes:startingAt:count: > ZdcSocketStream>>next:putAll:startingAt: > ZnBivalentWriteStream>>next:putAll:startingAt: > ZnUtils class>>nextPutAll:on: > ZnByteArrayEntity>>writeOn: > ZnEntityWriter>>writeEntity: > ZnRequest(ZnMessage)>>writeOn: > ZnRequest>>writeOn: > ZnClient>>executeRequestResponse > ZnClient>>getConnectionAndExecute in Block: [ self executeRequestResponse ] > BlockClosure>>ensure: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... > BlockClosure>>on:do: > ZnClient>>executeWithTimeout in Block: [ ... > ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ ... > BlockClosure>>ensure: > ZnConnectionTimeout(DynamicVariable)>>value:during: > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > ZnClient>>withTimeoutDo: > ZnClient>>executeWithTimeout > ZnClient>>execute in Block: [ result := self executeWithTimeout ] > ZnClient>>withProgressDo: in Block: [ ^ block value ] > ZnSignalProgress(DynamicVariable)>>value:during: in Block: [ ... > BlockClosure>>ensure: > > I tried to: > - Augment the client timeout to a huge value (10 mins) but it has no effect: The data send still goes into timeout, after 10-15 sec > - I replaced the ZnEntity with a ZnMultiPartFormDataEntity, still no luck > > I am wondering what else can I do. > > Moreover, I discovered there is a #signalProgress: message to signal process. The following examples do not work, any hint? > > ################################################################################ > Example 1, from the book @ http://zn.stfx.eu/zn/zinc-http-components-paper.html: > > UIManager default informUserDuring: [ :bar | > [ ^ ZnClient new > signalProgress: true; > get: 'http://zn.stfx.eu/echo?delay=2' ] > on: HTTPProgress > do: [ :progress | bar value: progress printString. progress resume ] ] > > ################################################################################ > Example 2, from ZnClientTests>>#testProgress works, but not when issuing a POST request > [ :bar | > bar title: 'Downloading Sources...'. > [ > ZnClient new > url: 'http://files.pharo.org/sources/PharoV30.sources'; > signalProgress: true; > downloadTo: FileLocator temp ] > on: HTTPProgress > do: [ :progress | > progress isEmpty ifFalse: [ bar current: progress percentage ]. > progress resume ] ] asJob run. > â¦works but only when using #downloadTo: if you do a #post:contents: or a #get: as in the example with #get: 'http://zn.stfx.eu/echo?delay=10' no process is shown. Any hint? > > Thanks in advance, > Roberto > >

June 6, 2014

installing raspberry pi

by Tudor Girba

Hi, I am at NDC Oslo, and a couple of guys want to play with it on a Raspberry Pi robot. Imagine that :). We tried this: http://pharoweekly.wordpress.com/2014/02/19/raspberrypi/ but, it seems that the link to the vm is no longer working. Can anyone point me to better instructions? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

June 6, 2014

Re: [Pharo-dev] can not upload a slice to pharo40 inbox

by Nicolai Hess

Thank you, it works now. 2014-06-06 10:49 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > As a workaround, I added you as a contributor to the inbox. > > On 05 Jun 2014, at 12:47, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > 2014-06-05 7:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Recently there was a bug in public repositories in smalltalkhub (non >> registered users were not able to commit as if the repo was private). It >> might be that. >> >> >> 2014-06-04 22:57 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >> when uploading a slice, I always get the following error: >>> >>> a ZnResponse(500 Internal Server Error text/plain;charset=utf-8 30B) >>> >>> any ideas? >>> >>> Nicolai >>> >> >> > >

June 6, 2014

Re: [Pharo-dev] github metacello pero and jenkins matrix builds

by Yuriy Tymchuk

On 06 Jun 2014, at 13:40, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Metacello implementation of the github protocol uses a zip file downloaded from github and then extracted in a temp folder. See https://github.com/dalehenrich/metacello-work/blob/master/repository/Metace… > Metacello code is not robust enough. It should check for a not-used temporary file name. Check MCGitHubRepository>>projectDirectoryFrom: version: > > zipFileName := '/tmp/github-' > , (downloadCacheKey select: [ :c | c isAlphaNumeric ]) , '.zip'. > > The problem is not related to Zinc. Thank you for explanation. > > So, Metacello should be fixed. As a workaround, you can also specify to run only 1 instance of your job at a time. This looks like meaningful walk around. Thanks again. Uko > > Christophe > > > Le 6 juin 2014 Ã 08:39, Yuriy Tymchuk a Ã©crit : > >> Looks like ZnFileSystemUtils are doing this. As far as i understand, the problem occurs when two matrix lobs run at the same time and so one downloads thing into /tmp, and other one encounters a problem. Isnât this some sort of bug in Zinc? >> >> Uko >> >> On 06 Jun 2014, at 11:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> >>> On 06 Jun 2014, at 11:19, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> >>>>> On 06.06.2014, at 07:28, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>> >>>>> Sorry for bothering guys, but I really get random errors. For example last one I saw is: >>>>> >>>>> An attempt to use interactive tools detected, while in non-interactive mode >>>>> FileDoesNotExistException: '/tmp/github-UkoVnaExportermaster.zip' >>>>> >>>>> Can anybody help me to localise the problem? Is the Jenkins configuration wrong? Or I should do things in a completely different way? >>>> >>>> Did you specigy /tmp as output folder? If so, you should use the working directory (which will be the build directory). You can not assume to have write permissions on /tmp. >>> >>> Yes, thatâs the thing. I guess /tmp is used by something in metacello-filetree-github toolchain. Thatâs why Iâm asking because Iâve never worked with is a lot. >>> >>> Uko >>> >>>> >>>>> >>>>> Uko >>>>> >>>>> On 31 May 2014, at 14:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> So Iâm using this fancy metacello github urls, like: github://<user>/<project>[:<branch>|<tag>|<SHA>][/<path>] and some of my Jenkins matrix builds are randomly failing with: >>>>>> >>>>>> Error: /tmp/github-UkoRenrakumaster.zip already exists >>>>>> >>>>>> anyone has an idea how to solve this? >>>>>> >>>>>> Uko >>>>> >>>> >>> >> >

June 6, 2014

Delete a package in SmalltalkHub

by jannik laval

Hi pharoers, In SmalltalkHub, we would like to delete a package in a team project. When clicking on delete button, we get a message: "The request did not succeed". Any idea ? -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

June 6, 2014

Re: [Pharo-dev] can not upload a slice to pharo40 inbox

by Marcus Denker

As a workaround, I added you as a contributor to the inbox. On 05 Jun 2014, at 12:47, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2014-06-05 7:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Recently there was a bug in public repositories in smalltalkhub (non registered users were not able to commit as if the repo was private). It might be that. > > > 2014-06-04 22:57 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > when uploading a slice, I always get the following error: > > a ZnResponse(500 Internal Server Error text/plain;charset=utf-8 30B) > > any ideas? > > Nicolai > >

June 6, 2014

ZnClient send big data + progress

by roberto.minelli＠usi.ch

Hi guys, I have a problem with Zinc, I need to send a huge amount of data (bytes) that translates to ~50Mb. When I do something like: ZnEasy post: 'http://localhost:15432' data: (ZnEntity bytes: aHugeByteArray.] I encounter a âConnectionTimedOut: Data send timed out.â, I attach the stack trace: ZdcSocketStream(ZdcSimpleSocketStream)>>flushBytes:startingAt:count: ZdcSocketStream>>next:putAll:startingAt: ZnBivalentWriteStream>>next:putAll:startingAt: ZnUtils class>>nextPutAll:on: ZnByteArrayEntity>>writeOn: ZnEntityWriter>>writeEntity: ZnRequest(ZnMessage)>>writeOn: ZnRequest>>writeOn: ZnClient>>executeRequestResponse ZnClient>>getConnectionAndExecute in Block: [ self executeRequestResponse ] BlockClosure>>ensure: ZnClient>>getConnectionAndExecute ZnClient>>executeWithRedirectsRemaining: ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... BlockClosure>>on:do: ZnClient>>executeWithRetriesRemaining: ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... BlockClosure>>on:do: ZnClient>>executeWithTimeout in Block: [ ... ZnClient>>withTimeoutDo: in Block: [ ^ block value ] ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ ... BlockClosure>>ensure: ZnConnectionTimeout(DynamicVariable)>>value:during: ZnConnectionTimeout class(DynamicVariable class)>>value:during: ZnClient>>withTimeoutDo: ZnClient>>executeWithTimeout ZnClient>>execute in Block: [ result := self executeWithTimeout ] ZnClient>>withProgressDo: in Block: [ ^ block value ] ZnSignalProgress(DynamicVariable)>>value:during: in Block: [ ... BlockClosure>>ensure: I tried to: - Augment the client timeout to a huge value (10 mins) but it has no effect: The data send still goes into timeout, after 10-15 sec - I replaced the ZnEntity with a ZnMultiPartFormDataEntity, still no luck I am wondering what else can I do. Moreover, I discovered there is a #signalProgress: message to signal process. The following examples do not work, any hint? ################################################################################ Example 1, from the book @ http://zn.stfx.eu/zn/zinc-http-components-paper.html: UIManager default informUserDuring: [ :bar | [ ^ ZnClient new signalProgress: true; get: 'http://zn.stfx.eu/echo?delay=2' ] on: HTTPProgress do: [ :progress | bar value: progress printString. progress resume ] ] ################################################################################ Example 2, from ZnClientTests>>#testProgress works, but not when issuing a POST request [ :bar | bar title: 'Downloading Sources...'. [ ZnClient new url: 'http://files.pharo.org/sources/PharoV30.sources'; signalProgress: true; downloadTo: FileLocator temp ] on: HTTPProgress do: [ :progress | progress isEmpty ifFalse: [ bar current: progress percentage ]. progress resume ] ] asJob run. â¦works but only when using #downloadTo: if you do a #post:contents: or a #get: as in the example with #get: 'http://zn.stfx.eu/echo?delay=10' no process is shown. Any hint? Thanks in advance, Roberto

June 6, 2014

Re: [Pharo-dev] github metacello pero and jenkins matrix builds

by Christophe Demarey

Metacello implementation of the github protocol uses a zip file downloaded from github and then extracted in a temp folder. See https://github.com/dalehenrich/metacello-work/blob/master/repository/Metace… Metacello code is not robust enough. It should check for a not-used temporary file name. Check MCGitHubRepository>>projectDirectoryFrom: version: zipFileName := '/tmp/github-' , (downloadCacheKey select: [ :c | c isAlphaNumeric ]) , '.zip'. The problem is not related to Zinc. So, Metacello should be fixed. As a workaround, you can also specify to run only 1 instance of your job at a time. Christophe Le 6 juin 2014 Ã 08:39, Yuriy Tymchuk a Ã©crit : > Looks like ZnFileSystemUtils are doing this. As far as i understand, the problem occurs when two matrix lobs run at the same time and so one downloads thing into /tmp, and other one encounters a problem. Isnât this some sort of bug in Zinc? > > Uko > > On 06 Jun 2014, at 11:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 06 Jun 2014, at 11:19, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>>> On 06.06.2014, at 07:28, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>> Sorry for bothering guys, but I really get random errors. For example last one I saw is: >>>> >>>> An attempt to use interactive tools detected, while in non-interactive mode >>>> FileDoesNotExistException: '/tmp/github-UkoVnaExportermaster.zip' >>>> >>>> Can anybody help me to localise the problem? Is the Jenkins configuration wrong? Or I should do things in a completely different way? >>> >>> Did you specigy /tmp as output folder? If so, you should use the working directory (which will be the build directory). You can not assume to have write permissions on /tmp. >> >> Yes, thatâs the thing. I guess /tmp is used by something in metacello-filetree-github toolchain. Thatâs why Iâm asking because Iâve never worked with is a lot. >> >> Uko >> >>> >>>> >>>> Uko >>>> >>>> On 31 May 2014, at 14:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> So Iâm using this fancy metacello github urls, like: github://<user>/<project>[:<branch>|<tag>|<SHA>][/<path>] and some of my Jenkins matrix builds are randomly failing with: >>>>> >>>>> Error: /tmp/github-UkoRenrakumaster.zip already exists >>>>> >>>>> anyone has an idea how to solve this? >>>>> >>>>> Uko >>>> >>> >> >

June 6, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Alexandre Bergel

It would also be amazing to have mouse wheel properly implemented in the VM. Or maybe we should just wait for the work of Ronie... Alexandre On Jun 4, 2014, at 5:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > A couple of weeks ago we started to plan Pharo4. This work became stagnated for many reasons, but mainly because I needed to travel to Argentina. > Now I'm slowly resuming the work and I wanted to share with you what we have been talking/dreaming. > In esence, we have two important drivers for this release: > > 1) Improving tools > Turns out that we have introduced a lot of kernel improvements (opal compiler, layouts, slots, etc.) and tools are still not aware of them. Even worst: we have traits since a lot of time and our tools are still now aware enough to provide good interoperability. > But not just that: we have introduced things that are not well used yet: keybindings (who do not want a better keybindings structure... coherent and editable?), spec should allow us to continue enhancing existing tools and to replace old ones. > > 2) Modularisation > One of the fundamental ideas behind Pharo is to provide a modular environment. But well... since Pharo start to the moment, we prepared things to allow it, but still few direct effort has been made. > In our dreams, Pharo should be built starting for a small kernel image and adding different modules to get a complete version. In this idea Pharo=Kernel+GUI(Morphic)+Tools. > This has huge advantages (I do not think is necesary to explain them, isn't ;)?) > > We brainstomed around this and we get this list of issues (not all of them directly related to the objectives, but well... good stuff also :) ) > > Web site: > - add catalog > - add videos > - enhance it in general > > Infrastructure: > - support more vm platforms > > VM: > - spur > - 64bits > - make vm embedable and UI independent (with SDL2 and OSWindow) > > Image: > - Modularisation > - Removing old compiler > - Repackage Morphic (to allow better modularisation) > - Athens (replace old bitblt) > > Tools > - Replace changes with Ombu/Epicea > - Replace sources with a better abstraction > - Git support inside image (with libgit2 + tools) > - Pass on Spec > - Include Glamour? > - Make Ring unloadable > - Fonts with FreeType > > And lots of bugfixes :) > > We would like to exchange ideas with you. > So, what do you think? > > Esteban > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 6, 2014

Re: [Pharo-dev] github metacello pero and jenkins matrix builds

by Yuriy Tymchuk

Looks like ZnFileSystemUtils are doing this. As far as i understand, the problem occurs when two matrix lobs run at the same time and so one downloads thing into /tmp, and other one encounters a problem. Isnât this some sort of bug in Zinc? Uko On 06 Jun 2014, at 11:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 06 Jun 2014, at 11:19, Max Leske <maxleske(a)gmail.com> wrote: > >> >>> On 06.06.2014, at 07:28, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Sorry for bothering guys, but I really get random errors. For example last one I saw is: >>> >>> An attempt to use interactive tools detected, while in non-interactive mode >>> FileDoesNotExistException: '/tmp/github-UkoVnaExportermaster.zip' >>> >>> Can anybody help me to localise the problem? Is the Jenkins configuration wrong? Or I should do things in a completely different way? >> >> Did you specigy /tmp as output folder? If so, you should use the working directory (which will be the build directory). You can not assume to have write permissions on /tmp. > > Yes, thatâs the thing. I guess /tmp is used by something in metacello-filetree-github toolchain. Thatâs why Iâm asking because Iâve never worked with is a lot. > > Uko > >> >>> >>> Uko >>> >>> On 31 May 2014, at 14:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>>> Hi guys, >>>> >>>> So Iâm using this fancy metacello github urls, like: github://<user>/<project>[:<branch>|<tag>|<SHA>][/<path>] and some of my Jenkins matrix builds are randomly failing with: >>>> >>>> Error: /tmp/github-UkoRenrakumaster.zip already exists >>>> >>>> anyone has an idea how to solve this? >>>> >>>> Uko >>> >> >

June 6, 2014