February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [regression reporter]regression occurred

by Tudor Girba

The next integration will happen tomorrow. Andrei is preparing it. Doru -- www.tudorgirba.com "Every thing has its own flow" > On 25 Feb 2015, at 16:11, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi, >> When will this happen? this test fails since *WEEKS*, yet I could have fixed it in 5 minutes. But I canât. >> We make ourselves completely powerless. This does not make me feel good. > > Normally GT should be released more often. This time while Jenkins was down we did a lot of changes and now it takes some time to prepare everything for integration. Also at the moment of previous release moose didn't run tests like BehaviourTest and others. :) > > Cheers, > Alex > >> On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> On 25 Feb 2015, at 16:04, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>> >>> Hi, >>> >>> It is already fixed and will be integrated with GT >>> >> >> When will this happen? this test fails since *WEEKS*, yet I could have fixed it in 5 minutes. But I canât. >> We make ourselves completely powerless. This does not make me feel good. >> >> >>>> On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: >>>> Number>>#brickValue: must die ! >>>> >>>> > On 25 Feb 2015, at 15:53, no-reply(a)ci.inria.fr wrote: >>>> > >>>> > https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/labe… >>>> > >>>> > 1 regressions found. >>>> > KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses >>>> >>>> >> >

Feb. 25, 2015

Re: [Pharo-dev] GTInspector is slow for large strings

by Andrei Chis

Hi Alain, On Wed, Feb 25, 2015 at 10:55 PM, Alain Plantec via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Alain Plantec <alain.plantec(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Date: Wed, 25 Feb 2015 22:55:21 +0100 > Subject: Re: [Pharo-dev] GTInspector is slow for large strings > Iâve tried this: > > [ 'http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl > retrieveContents ] timeToRun 0:00:00:02.587 > > [ > GTInspector setGTInspectorEnabledStatus: false > ('http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl > retrieveContents) inspect ] timeToRun 0:00:00:02.877 > > [ GTInspector setGTInspectorEnabledStatus: true. > ('http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl > retrieveContents) inspect ] timeToRun 0:00:00:50.129 > > [ > RubScrolledTextMorph new > openInWorld; > updateTextWith: ( 'http://picasaweb.google.com/data/feed/api/all?q=puppy' > asUrl > retrieveContents) ] timeToRun 0:00:00:04.543 > > > So, Rubric takes 2 seconds to open and show this big text, > the basic inspector takes 0.3 seconds to open but it shows the first > characters only. > GTInspector takes 50 seconds. > > I think the problems comes from GTInspector itself. > From MorphTreeMorph maybe which is used by GTInspector > > Thanks for investigating this. I've opened an issue. https://pharo.fogbugz.com/f/cases/14994/GTInspector-is-slow-for-large-strin… Cheers, Andrei > Cheers > Alain > > > Le 25 fÃ©vr. 2015 Ã 22:24, Andrei Chis <chisvasileandrei(a)gmail.com> a > Ã©crit : > > Hi, > > It takes such a long time because for String objects the default > presentation shows the content of the String. In this case the string has > 10 million characters which Rubric takes some time to display. > > Given you use case it could make sense to limit by default the size of > content that is displayed and when this happens add an action for showing > the entire content. > > Cheers, > Andrei > > On Wed, Feb 25, 2015 at 8:57 PM, Damien Cassou <damien.cassou(a)gmail.com> > wrote: > >> Hi, >> >> if you inspect the following in Pharo 4, it will take a long time to >> execute: >> >> 'http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl >> retrieveContents. >> >> >> but if you execute this before, the inspecting above expression is much >> faster: >> >> GTInspector setGTInspectorEnabledStatus: false. >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill >> >> > > >

Feb. 25, 2015

Re: [Pharo-dev] GTInspector is slow for large strings

by Alain Plantec

Iâve tried this: [ 'http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl retrieveContents ] timeToRun 0:00:00:02.587 [ GTInspector setGTInspectorEnabledStatus: false ('http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl retrieveContents) inspect ] timeToRun 0:00:00:02.877 [ GTInspector setGTInspectorEnabledStatus: true. ('http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl retrieveContents) inspect ] timeToRun 0:00:00:50.129 [ RubScrolledTextMorph new openInWorld; updateTextWith: ( 'http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl retrieveContents) ] timeToRun 0:00:00:04.543 So, Rubric takes 2 seconds to open and show this big text, the basic inspector takes 0.3 seconds to open but it shows the first characters only. GTInspector takes 50 seconds. I think the problems comes from GTInspector itself. >From MorphTreeMorph maybe which is used by GTInspector Cheers Alain > Le 25 fÃ©vr. 2015 Ã 22:24, Andrei Chis <chisvasileandrei(a)gmail.com> a Ã©crit : > > Hi, > > It takes such a long time because for String objects the default presentation shows the content of the String. In this case the string has 10 million characters which Rubric takes some time to display. > > Given you use case it could make sense to limit by default the size of content that is displayed and when this happens add an action for showing the entire content. > > Cheers, > Andrei > > On Wed, Feb 25, 2015 at 8:57 PM, Damien Cassou <damien.cassou(a)gmail.com <mailto:damien.cassou@gmail.com>> wrote: > Hi, > > if you inspect the following in Pharo 4, it will take a long time to > execute: > > 'http://picasaweb.google.com/data/feed/api/all?q=puppy <http://picasaweb.google.com/data/feed/api/all?q=puppy>' asUrl > retrieveContents. > > > but if you execute this before, the inspecting above expression is much > faster: > > GTInspector setGTInspectorEnabledStatus: false. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/> > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

Feb. 25, 2015

Re: [Pharo-dev] GTInspector is slow for large strings

by Andrei Chis

Hi, It takes such a long time because for String objects the default presentation shows the content of the String. In this case the string has 10 million characters which Rubric takes some time to display. Given you use case it could make sense to limit by default the size of content that is displayed and when this happens add an action for showing the entire content. Cheers, Andrei On Wed, Feb 25, 2015 at 8:57 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > if you inspect the following in Pharo 4, it will take a long time to > execute: > > 'http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl > retrieveContents. > > > but if you execute this before, the inspecting above expression is much > faster: > > GTInspector setGTInspectorEnabledStatus: false. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

Feb. 25, 2015

GTInspector is slow for large strings

by Damien Cassou

Hi, if you inspect the following in Pharo 4, it will take a long time to execute: 'http://picasaweb.google.com/data/feed/api/all?q=puppy' asUrl retrieveContents. but if you execute this before, the inspecting above expression is much faster: GTInspector setGTInspectorEnabledStatus: false. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 25, 2015

Re: [Pharo-dev] zipped and unzipped methods for ByteArray

by Nicolas Cellier

I think I did something similar in Squeak, but can't remember exactly... http://source.squeak.org/trunk/Compression-nice.43.diff http://source.squeak.org/trunk/Compression-nice.44.diff ByteString zipped should better return a ByteArray because the zipped thing is all but a String (it is encoded...) But if we do this then what happens to WideString zipped ??? what should it be ??? Are we sure that we can unzip it back to a WideString ? My answer was that ByteString zipped -> ByteArray -> ByteString and WideString zipped -> ByteArray -> WideString, but it supposes that the zipped byte array has a length multiple of 4... Then I don't remember if it really works for WideString... But String is just a facade, all the effective job is performed in ByteArray. 2015-02-25 16:52 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > > > 25. 2. 2015 v 12:28, Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > This seems related to adding 'easy of use' methods to String. > > > > There are many different compression schemes (zip, bzip, bzip2, gzip, > ...), are we going to add them all ? > > > > How much do we want to couple different parts of the system ? > > I prefer to couple the compression schemes with String and ByteArray. > Methods like #zipped, #unzipped are not that simple and it is not well > apparent how to use that compression scheme. > > Cheers, > Juraj > > > > >> On 25 Feb 2015, at 16:23, Juraj Kubelka <juraj.kubelka(a)gmail.com> > wrote: > >> > >> Can I add ByteArray>>#zipped and #unzipped methods the way it is for > String? I want to compress bytes before sending through internet, for > example. > >> > >> Do you agree? > >> Thanks, > >> Juraj > > > > > > >

Feb. 25, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40511 Home: https://github.com/pharo-project/pharo-core

Feb. 25, 2015

[pharo-project/pharo-core] 0abda6: 40511

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 0abda64c057ec0761909ee9b6258587943fb20c2 https://github.com/pharo-project/pharo-core/commit/0abda64c057ec0761909ee9b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-25 (Wed, 25 Feb 2015) Changed paths: A Kernel.package/Context.class/instance/instruction decoding/unusedBytecode.st A Kernel.package/InstructionClient.class/instance/instruction decoding/unusedBytecode.st M Kernel.package/InstructionStream.class/instance/decoding/interpretNextV3PlusClosureInstructionFor_.st A Kernel.package/InstructionStream.class/instance/decoding/unusedBytecode_at_.st M ScriptLoader40.package/ScriptLoader.class/instance/ci/generateScriptAndUpdateMethodForNewVersionSilentlyConfigurations_preLoad_postLoad_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script510.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script511.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40510.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40511.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/ExampleSlotWithDefaultValue.class/README.md A Slot.package/ExampleSlotWithDefaultValue.class/class/as yet unclassified/default_.st M Slot.package/ExampleSlotWithDefaultValue.class/definition.st A Slot.package/ExampleSlotWithDefaultValue.class/instance/accessing/default_.st A Slot.package/ExampleSlotWithDefaultValue.class/instance/as yet unclassified/printOn_.st M Slot.package/ExampleSlotWithDefaultValue.class/instance/initialization/initialize_.st M Slot.package/PropertyBaseSlot.class/instance/initalize/initialize.st M Slot.package/Slot.class/instance/printing/printOn_.st M Slot.package/Slot.class/instance/printing/storeOn_.st Log Message: ----------- 40511 14991 ExampleSlotWithDefaultValue: allow default to be set in definition https://pharo.fogbugz.com/f/cases/14991 14992 ScriptLoader: code path of Integrator needs to delete scripts, too https://pharo.fogbugz.com/f/cases/14992 14982 Improved support for unknown bytecode https://pharo.fogbugz.com/f/cases/14982 http://files.pharo.org/image/40/40511.zip

Feb. 25, 2015

Re: [Pharo-dev] OSProcess bug ?

by jannik laval

Hi Levente, Nop, I catch also stderr, but there is nothing here. Jannik 2015-02-25 17:40 GMT+01:00 Levente Uzonyi <leves(a)elte.hu>: > Another possibility is that the program is writing to stderr instead of > stdout. > > Levente > > > On Wed, 25 Feb 2015, David T. Lewis wrote: > > Hi Jannik, >> >> One other thing I just thought of: Check and see if your rostopic program >> is actually writing to standard output, as opposed to writing directly to >> /dev/tty. From a terminal window, I think you could do this: >> >> $ rostopic > out.txt >> >> If you run this get output written to the out.txt file, that is good. If >> you run it and see output to your terminal window, it would mean that the >> rostopic program was writing directly to /dev/tty (so there would never be >> any output to read with a PipeableOSProcess). >> >> I would not worry about the missing AioPlugin. Your code should still work >> without the plugin. >> >> Dave >> >> >> Hi Dave, >>> >>> 2015-02-25 1:13 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: >>> >>> On Tue, Feb 24, 2015 at 08:33:41PM +0100, jannik laval wrote: >>>> >>>>> Hi pharoers, >>>>> >>>>> I am playing with OSProcess. >>>>> I am using an example, and I am annoyed with a strange bug: >>>>> >>>>> Here is the code I want to execute, and does not work: >>>>> ==== >>>>> |thread process output| >>>>> myCmd := 'rostopic bw /turtle1/pose'. >>>>> thread := [process := (PipeableOSProcess command: myCmd) ] fork. >>>>> 3 second wait. >>>>> output := process upToEnd. >>>>> output inspect. >>>>> thread terminate. >>>>> === >>>>> >>>> >>>> Hi Jannik, >>>> >>>> I am not familiar with the rostopic command, but it is common for some >>>> Unix programs to flush their output when the stdout is connected to >>>> /dev/tty (a terminal), but not necessarily if connected to a pipe or >>>> to a file. So it may be that the running rostopic program is producing >>>> output, but that the output has not yet been flushed to the pipe >>>> connected >>>> to your PipeableOSProcess. >>>> >>>> >>> Thank you for your explanation. >>> So, what I can do is to send a sigint to terminate the process and >>> receive >>> the info. >>> But sending "process processProxy sigint." does nothing. >>> >>> By the way I have a warning on the AIOPlugin... Probably I should >>> reinstall >>> my VM. >>> >>> I also try "process flush", but it does not do anything. >>> >>> >>> >>> >>>> Your #upToEnd call will read the available data from the OS pipe, but it >>>> will not read data that was "written" by the rotopic program, but not >>>> yet flushed out to the OSPipe. So I am guessing that this may be why the >>>> data seems to be missing. >>>> >>>> I notice also that you are putting your PipeableOSProcess into a >>>> separate >>>> Smalltalk process using #fork. This is probably not necessary, so try >>>> getting rid of the #fork and the later thread terminate. It will not fix >>>> the problem for you, but it will simplify the code. >>>> >>>> >>> >>> Ok, it is simpler like that. You are right, it does not help :) >>> >>> Thank you for your help. >>> >>> >>> >>>> Dave >>>> >>>> >>>> >>>>> 'rostopic bw /turtle1/pose' is a command that is a loop displaying the >>>>> current bandwidth of a ROS process. In a terminal, it works fine. With >>>>> OSProcess the output value is empty. >>>>> >>>>> My source code is correct: if I replace myCmd by : >>>>> myCmd := 'ping localhost'. >>>>> >>>>> It is a loop too, and it returns a correct string. >>>>> >>>>> I have clearly no idea of where I have to search... Any help or >>>>> >>>> discussion >>>> >>>>> about that would be great :) >>>>> >>>>> Thank you, >>>>> >>>>> Oups, some infos: >>>>> I am using Ubuntu 14.04 >>>>> Pharo3.0 with Moose 5.0, latest update: #30863 >>>>> The script I use (rostopic) is a python script (does it impact ?) >>>>> >>>>> >>>>> -- >>>>> >>>>> ~~Jannik Laval~~ >>>>> ??cole des Mines de Douai >>>>> Enseignant-chercheur >>>>> http://www.jannik-laval.eu >>>>> http://www.phratch.com >>>>> http://www.approchealpes.info >>>>> http://car.mines-douai.fr/ >>>>> >>>> >>>> >>>> >>> >>> -- >>> >>> ~~Jannik Laval~~ >>> Ã?cole des Mines de Douai >>> Enseignant-chercheur >>> http://www.jannik-laval.eu >>> http://www.phratch.com >>> http://www.approchealpes.info >>> http://car.mines-douai.fr/ >>> >>> >> >> >> -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

Feb. 25, 2015

Re: [Pharo-dev] OSProcess bug ?

by jannik laval

Hi Dave, 2015-02-25 17:05 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > Hi Jannik, > > One other thing I just thought of: Check and see if your rostopic program > is actually writing to standard output, as opposed to writing directly to > /dev/tty. From a terminal window, I think you could do this: > > $ rostopic > out.txt > Yes, it writes on the file after a ctrl-c. > > If you run this get output written to the out.txt file, that is good. If > you run it and see output to your terminal window, it would mean that the > rostopic program was writing directly to /dev/tty (so there would never be > any output to read with a PipeableOSProcess). > > I would not worry about the missing AioPlugin. Your code should still work > without the plugin. > Ok, thank you. Jannik > > Dave > > > > Hi Dave, > > > > 2015-02-25 1:13 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > > > >> On Tue, Feb 24, 2015 at 08:33:41PM +0100, jannik laval wrote: > >> > Hi pharoers, > >> > > >> > I am playing with OSProcess. > >> > I am using an example, and I am annoyed with a strange bug: > >> > > >> > Here is the code I want to execute, and does not work: > >> > ==== > >> > |thread process output| > >> > myCmd := 'rostopic bw /turtle1/pose'. > >> > thread := [process := (PipeableOSProcess command: myCmd) ] fork. > >> > 3 second wait. > >> > output := process upToEnd. > >> > output inspect. > >> > thread terminate. > >> > === > >> > >> Hi Jannik, > >> > >> I am not familiar with the rostopic command, but it is common for some > >> Unix programs to flush their output when the stdout is connected to > >> /dev/tty (a terminal), but not necessarily if connected to a pipe or > >> to a file. So it may be that the running rostopic program is producing > >> output, but that the output has not yet been flushed to the pipe > >> connected > >> to your PipeableOSProcess. > >> > > > > Thank you for your explanation. > > So, what I can do is to send a sigint to terminate the process and > receive > > the info. > > But sending "process processProxy sigint." does nothing. > > > > By the way I have a warning on the AIOPlugin... Probably I should > > reinstall > > my VM. > > > > I also try "process flush", but it does not do anything. > > > > > > > >> > >> Your #upToEnd call will read the available data from the OS pipe, but it > >> will not read data that was "written" by the rotopic program, but not > >> yet flushed out to the OSPipe. So I am guessing that this may be why the > >> data seems to be missing. > >> > >> I notice also that you are putting your PipeableOSProcess into a > >> separate > >> Smalltalk process using #fork. This is probably not necessary, so try > >> getting rid of the #fork and the later thread terminate. It will not fix > >> the problem for you, but it will simplify the code. > >> > > > > > > Ok, it is simpler like that. You are right, it does not help :) > > > > Thank you for your help. > > > > > >> > >> Dave > >> > >> > >> > > >> > 'rostopic bw /turtle1/pose' is a command that is a loop displaying the > >> > current bandwidth of a ROS process. In a terminal, it works fine. With > >> > OSProcess the output value is empty. > >> > > >> > My source code is correct: if I replace myCmd by : > >> > myCmd := 'ping localhost'. > >> > > >> > It is a loop too, and it returns a correct string. > >> > > >> > I have clearly no idea of where I have to search... Any help or > >> discussion > >> > about that would be great :) > >> > > >> > Thank you, > >> > > >> > Oups, some infos: > >> > I am using Ubuntu 14.04 > >> > Pharo3.0 with Moose 5.0, latest update: #30863 > >> > The script I use (rostopic) is a python script (does it impact ?) > >> > > >> > > >> > -- > >> > > >> > ~~Jannik Laval~~ > >> > ??cole des Mines de Douai > >> > Enseignant-chercheur > >> > http://www.jannik-laval.eu > >> > http://www.phratch.com > >> > http://www.approchealpes.info > >> > http://car.mines-douai.fr/ > >> > >> > > > > > > -- > > > > ~~Jannik Laval~~ > > Ãcole des Mines de Douai > > Enseignant-chercheur > > http://www.jannik-laval.eu > > http://www.phratch.com > > http://www.approchealpes.info > > http://car.mines-douai.fr/ > > > > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

Feb. 25, 2015