Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI
Which is a pain as when I copy/paste a shell script full of those, I won't
do that.
Is this also doing the same thing in blocks like:
[[[label=.bashrc|caption=Ajouts à .bashrc|language=bash
${SOMEVAR:-}
]]]
I am not gonna escape those things as what happens is copy/pasting code.
That there are no such directives in Markdiwn is what makes it nice to use
and hassle free.
I would escape your directives and leave the core of the text alone.
Well, what do you think?
Phil
On Wed, Sep 30, 2015 at 10:38 PM, Ferlicot D. Cyril <
cyril.ferli...@gmail.com> wrote:
> Le 30/09/2015 22:32, p...@highoctane.be a écrit :
> > Downloaded the book-skeleton, patched the download script so that it
> > gets the centos things right and the Pharo4VM.
> >
> > Now, changes in Pillar made my books unsuable, namely the introduction
> > of things like this:
> >
> > ${tag:parameter=value|parameter2=value2}$
> >
> >
> > made contents with bash shell scripts unparsable.
> >
> >
> > Yeah, but there are often such things.
> >
> >
> > Like in:
> >
> >
> > Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui
> > couvre une période plus courte
> >
> >
> > How do I solve that with the new markup?
> >
> >
> > Phil
> >
> >
> >
>
> You can just escape like this:
>
> Il existe une autre variable ==\${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui
> couvre une période plus courte
>
> :)
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
>
Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI
Le 30/09/2015 22:32, p...@highoctane.be a écrit :
> Downloaded the book-skeleton, patched the download script so that it
> gets the centos things right and the Pharo4VM.
>
> Now, changes in Pillar made my books unsuable, namely the introduction
> of things like this:
>
> ${tag:parameter=value|parameter2=value2}$
>
>
> made contents with bash shell scripts unparsable.
>
>
> Yeah, but there are often such things.
>
>
> Like in:
>
>
> Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui
> couvre une période plus courte
>
>
> How do I solve that with the new markup?
>
>
> Phil
>
>
>
You can just escape like this:
Il existe une autre variable ==\${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui
couvre une période plus courte
:)
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
signature.asc
Description: OpenPGP digital signature
Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI
Downloaded the book-skeleton, patched the download script so that it gets
the centos things right and the Pharo4VM.
Now, changes in Pillar made my books unsuable, namely the introduction of
things like this:
${tag:parameter=value|parameter2=value2}$
made contents with bash shell scripts unparsable.
Yeah, but there are often such things.
Like in:
Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui
couvre une période plus courte
How do I solve that with the new markup?
Phil
On Wed, Sep 30, 2015 at 7:57 PM, Ferlicot D. Cyril
wrote:
>
> Le 30/09/2015 18:38, p...@highoctane.be a écrit :
> > Hello,
> >
> > It may have been a long time without it but still...
> >
> > I ran the doc job on my CI and got this that wasn't working:
> >
> >
https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/Pillar.zip
> >
> > Hum, yes, but ... why remove the doc tools as this is quite an important
> > thing to keep around for all Pharo versions?
> >
> > I'll go to 4.0 but there are other dependencies etc for the OS maybe
etc.
> > Not good as I need to migrate these things for my customer as well.
> >
> > Phil
>
> Hi Phil,
>
> We removed the Pillar job for Pharo 3 because we introduced an new
> feature not backward compatible.
> So we freezed the Pillar version for Pharo 3. So we do not need a job
> for it anymore since it will not change and we do not want to keep a red
> job for "Pillar - Pharo 3 - Development".
>
> You can still load the stable version of Pillar in Pharo 3, but this
> version will not evolve anymore.
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
Re: [Pharo-users] Custom type inference and RoelTyper
Type system is particularly complicated. I did a first implementation (called Type4Pharo on smalltalkhub), but it does not go in the right direction. I will redo it completely. So, nothing will be ready until a few months. Alexandre > On Sep 30, 2015, at 10:01 PM, Peter Uhnak wrote: > > Good to hear! > > Do you have any time estimation (days/weeks)? Also I don't mind looking at > something incomplete (after all I learned roassal just from source code ;)) > > Thanks, > Peter > From: Tudor Girba > Sent: 9/30/2015 9:43 PM > To: Any question about pharo is welcome > Cc: Moose-related development > Subject: Re: [Pharo-users] Custom type inference and RoelTyper > > Great news :) > > Doru > > On Wed, Sep 30, 2015 at 9:31 PM, Alexandre Bergel > wrote: > Hi Peter! > > I am currently working on gradual typing for Pharo. > I hope to have something ready for public consumption soon... > > Alexandre > > > > On Sep 30, 2015, at 8:28 PM, Peter Uhnak wrote: > > > > Hi, > > > > Moose/FAMIX uses RoelTyper for type inference, how this does not seem to be > > maintained (last version 2013), and for my purposes is lacking. > > > > So do we have something more advanced, even at the expense of speed? > > > > Other alternative would be to either extend RoelTyper or write something > > custom that would be ran alongside RoelTyper. > > > > Examples of such extensions would be extracting the type from > > meta-annotations and the actual argument names. (e.g. if an argument is > > named aString, I can safely assume that it will be String). > > > > Thanks, > > Peter > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-users] Accessors vs instance variables
Hi, > On 30 Sep 2015, at 21:35, Lyn Headley wrote: > > Hello, > > As I understand it, in Smalltalk, the instance variables of a class C are > "protected" - able to be referenced by methods of C or its subclasses, but > not by other objects. This is a useful feature as it clearly points out which > pieces of data are not available to other objects, and thereby simplifies > code. > > However, I am often unsure of whether to use this feature or not, as it > conflicts in my mind with the practice of using accessor methods. I like > accessor methods because they make it easy to change behavior later -- If I > have a dozen calls to an accessor method, then I only need to change it in > one place. If these were instance variable references, I would have to do > more work. The disadvantage of accessor methods is that they obscure the > protected status of data -- it becomes unclear how protected an instance > variable is meant to be. (Accessors also make it harder for me to find users > of the data when browsing, when there are senders from totally unrelated > classes, although I suspect I have just not figured out how to browse scoped > in the right way for this). > > It occurs to me that a tool could be (easily?) developed that would solve > this problem. It would take existing variable references and turn them into > calls to accessor methods. That way, I could have protection when I want it, > and easy ability to change code as well. Does something like this exist, or > is it feasible to build? > > How do others think about this issue? > > -Lyn I think that with the current options in the tools (auto generation of accessors based on instance variables, checking references to instance variables, renaming either accessors or instance variables, syntax coloring) the difference between the two is becoming somewhat smaller. I used to consistently use accessors for the reasons you describe, but lately I find it more important to think as object oriented as possible, to maximise encapsulation and minimise the interface to the outside world. Now, I only add accessors if that really makes sense, the lack of accessors should then signal the private nature of the instance variable. Sven
Re: [Pharo-users] Custom type inference and RoelTyper
Good to hear! Do you have any time estimation (days/weeks)? Also I don't mind looking at something incomplete (after all I learned roassal just from source code ;)) Thanks, Peter -Original Message- From: "Tudor Girba" Sent: 9/30/2015 9:43 PM To: "Any question about pharo is welcome" Cc: "Moose-related development" Subject: Re: [Pharo-users] Custom type inference and RoelTyper Great news :) Doru On Wed, Sep 30, 2015 at 9:31 PM, Alexandre Bergel wrote: Hi Peter! I am currently working on gradual typing for Pharo. I hope to have something ready for public consumption soon... Alexandre > On Sep 30, 2015, at 8:28 PM, Peter Uhnak wrote: > > Hi, > > Moose/FAMIX uses RoelTyper for type inference, how this does not seem to be > maintained (last version 2013), and for my purposes is lacking. > > So do we have something more advanced, even at the expense of speed? > > Other alternative would be to either extend RoelTyper or write something > custom that would be ran alongside RoelTyper. > > Examples of such extensions would be extracting the type from > meta-annotations and the actual argument names. (e.g. if an argument is named > aString, I can safely assume that it will be String). > > Thanks, > Peter -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com "Every thing has its own flow"
[Pharo-users] Code completion in comment pane and Pillar
Hi, Some time ago I ran into a problem with typing left brackets into comment pane. As you know, code blocks in Pillar are marked with [[[ However comment pane is subject to regular code completion of NECController, which means that every time I type '[' NEC converts it into '[ ]'. So if I type '[[[' then I get '[ [ [ ] ] ]'. Which is good in code, but not here. Now considering we are pushing for Pillar in comments I think this should be resolved. However I don't know how. a) disable code completion for comments (trivial, but loosing CC b) subclass NECController to disable this. This is probably lot more complex, because the current one is hard-wired via Smalltalk tools c) add configuration option to NECControler so it can run in different modes (still a lot of work) d) add setting to options to disable/enable CC in comments and let users decide. d) other better, faster, easier solution? >From future perspective b) could be used to provide more extensive code >completion, specifically for Pillar. Thanks, Peter
Re: [Pharo-users] Custom type inference and RoelTyper
Great news :) Doru On Wed, Sep 30, 2015 at 9:31 PM, Alexandre Bergel wrote: > Hi Peter! > > I am currently working on gradual typing for Pharo. > I hope to have something ready for public consumption soon... > > Alexandre > > > > On Sep 30, 2015, at 8:28 PM, Peter Uhnak wrote: > > > > Hi, > > > > Moose/FAMIX uses RoelTyper for type inference, how this does not seem to > be maintained (last version 2013), and for my purposes is lacking. > > > > So do we have something more advanced, even at the expense of speed? > > > > Other alternative would be to either extend RoelTyper or write something > custom that would be ran alongside RoelTyper. > > > > Examples of such extensions would be extracting the type from > meta-annotations and the actual argument names. (e.g. if an argument is > named aString, I can safely assume that it will be String). > > > > Thanks, > > Peter > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- www.tudorgirba.com "Every thing has its own flow"
[Pharo-users] Accessors vs instance variables
Hello, As I understand it, in Smalltalk, the instance variables of a class C are "protected" - able to be referenced by methods of C or its subclasses, but not by other objects. This is a useful feature as it clearly points out which pieces of data are not available to other objects, and thereby simplifies code. However, I am often unsure of whether to use this feature or not, as it conflicts in my mind with the practice of using accessor methods. I like accessor methods because they make it easy to change behavior later -- If I have a dozen calls to an accessor method, then I only need to change it in one place. If these were instance variable references, I would have to do more work. The disadvantage of accessor methods is that they obscure the protected status of data -- it becomes unclear how protected an instance variable is meant to be. (Accessors also make it harder for me to find users of the data when browsing, when there are senders from totally unrelated classes, although I suspect I have just not figured out how to browse scoped in the right way for this). It occurs to me that a tool could be (easily?) developed that would solve this problem. It would take existing variable references and turn them into calls to accessor methods. That way, I could have protection when I want it, and easy ability to change code as well. Does something like this exist, or is it feasible to build? How do others think about this issue? -Lyn
Re: [Pharo-users] Custom type inference and RoelTyper
Hi Peter! I am currently working on gradual typing for Pharo. I hope to have something ready for public consumption soon... Alexandre > On Sep 30, 2015, at 8:28 PM, Peter Uhnak wrote: > > Hi, > > Moose/FAMIX uses RoelTyper for type inference, how this does not seem to be > maintained (last version 2013), and for my purposes is lacking. > > So do we have something more advanced, even at the expense of speed? > > Other alternative would be to either extend RoelTyper or write something > custom that would be ran alongside RoelTyper. > > Examples of such extensions would be extracting the type from > meta-annotations and the actual argument names. (e.g. if an argument is named > aString, I can safely assume that it will be String). > > Thanks, > Peter -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI
Ok, where? Phil On Wed, Sep 30, 2015 at 7:57 PM, Ferlicot D. Cyril wrote: > Le 30/09/2015 18:38, p...@highoctane.be a écrit : > > Hello, > > > > It may have been a long time without it but still... > > > > I ran the doc job on my CI and got this that wasn't working: > > > > > https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/Pillar.zip > > > > Hum, yes, but ... why remove the doc tools as this is quite an important > > thing to keep around for all Pharo versions? > > > > I'll go to 4.0 but there are other dependencies etc for the OS maybe etc. > > Not good as I need to migrate these things for my customer as well. > > > > Phil > > Hi Phil, > > We removed the Pillar job for Pharo 3 because we introduced an new > feature not backward compatible. > So we freezed the Pillar version for Pharo 3. So we do not need a job > for it anymore since it will not change and we do not want to keep a red > job for "Pillar - Pharo 3 - Development". > > You can still load the stable version of Pillar in Pharo 3, but this > version will not evolve anymore. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >
[Pharo-users] Custom type inference and RoelTyper
Hi, Moose/FAMIX uses RoelTyper for type inference, how this does not seem to be maintained (last version 2013), and for my purposes is lacking. So do we have something more advanced, even at the expense of speed? Other alternative would be to either extend RoelTyper or write something custom that would be ran alongside RoelTyper. Examples of such extensions would be extracting the type from meta-annotations and the actual argument names. (e.g. if an argument is named aString, I can safely assume that it will be String). Thanks, Peter
Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI
Le 30/09/2015 18:38, p...@highoctane.be a écrit : > Hello, > > It may have been a long time without it but still... > > I ran the doc job on my CI and got this that wasn't working: > > https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/Pillar.zip > > Hum, yes, but ... why remove the doc tools as this is quite an important > thing to keep around for all Pharo versions? > > I'll go to 4.0 but there are other dependencies etc for the OS maybe etc. > Not good as I need to migrate these things for my customer as well. > > Phil Hi Phil, We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible. So we freezed the Pillar version for Pharo 3. So we do not need a job for it anymore since it will not change and we do not want to keep a red job for "Pillar - Pharo 3 - Development". You can still load the stable version of Pillar in Pharo 3, but this version will not evolve anymore. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France signature.asc Description: OpenPGP digital signature
[Pharo-users] Pillar for 30 gone the way of the dodo on the CI
Hello, It may have been a long time without it but still... I ran the doc job on my CI and got this that wasn't working: https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/Pillar.zip Hum, yes, but ... why remove the doc tools as this is quite an important thing to keep around for all Pharo versions? I'll go to 4.0 but there are other dependencies etc for the OS maybe etc. Not good as I need to migrate these things for my customer as well. Phil
[Pharo-users] Rubric events
Hello, I'm working on modifying the styling of text by using RubTextSegmentMorph. The problem is that the text could be modified dynamically by selecting another text, so the styling must be modified. I want to use the announcements system of Rubric but something weird happens. When I subscribe to the announce RubTextUpdatedInModel of the RubScrolledTextMorph, the styling sometimes works, sometimes doesn't. What I noticed in the method RubScrolledTextMorph>>whenTextUpdatedInModel: the announcement is done before setting the text in the morph and if I change this to make the announcement after setting the text, everything works fine. So my question is: Is there something special to announcer the set of the text before actually setting it? Is it ok to change it? OR Is another way to do what I want to do? Bests, Miguel
Re: [Pharo-users] Pharo - database without database
Hello, looking forward to use it :) Adam. Dne Po 28. září 2015 16:38:58, Dale Henrichs napsal(a): > Adam, > > Keep an eye on the GLASS list[1] for an upcoming (within 2 months - I > promise:) announcement about GsDevKit_home (not to be confused with > gsDevKitHome:)... as it will provide much needed support for > creating/starting/managing multiple GemStone stones If you are > interested in working with GemStone:) > > Dale > > [1] http://forum.world.st/GLASS-f1460844.html > > On 09/28/2015 12:48 PM, Adam wrote: > > Hello, > > > > Yes, I was confused by some old discussion. New licence is different. > > Thanks for correction. > > > > Adam. > > > > Dne Po 28. září 2015 12:17:19, Stephan Eggermont napsal(a): > >> On 27-09-15 18:47, Adam wrote: > >>> 1) Object memory limit: Current object memory of Pharo is limited to > >>> 4GB. > >>> Free version of GemStone/S is also limited to 4GB, so I would rather > >>> stick with Pharo until I reach this level. And in the future this limit > >>> grow due to 64bit version of VM. > >> > >> The information on GemStone seems incorrect. > >> https://gemtalksystems.com/licensing/ > >> What I read there is that the Limited (email address required) license > >> supports 50 GB of (on-disk) objects, with a 2GB shared page cache. > >> > >> Stephan
Re: [Pharo-users] Zn / Connection closed while waiting for data
In my case it's still failing with 'Connection closed while waiting for data.' Cheers, Andrei On Wed, Sep 30, 2015 at 9:29 AM, Sven Van Caekenberghe wrote: > > > On 30 Sep 2015, at 08:16, Volkert > wrote: > > > > For your information: today i tried again and know it works as expected > ... > > OK, thanks for letting us know. > > > Same net > > Same pharo-vm/image > > Same ubuntu/kernel > > > > Strange maybe the "blood moon" on monday ... > > Yes, weird. > > > $ ./pharo Pharo.image eval "' > http://bl.ocks.org/ostock/raw/4063318/dji.csv' asUrl retrieveContents" > > 'Date,Open,High,Low,Close,Volume,Adj Close > > 2010-10-01,10789.72,10907.41,10759.14,10829.68,429891,10829.68 > > 2010-09-30,10835.96,10960.99,10732.27,10788.05,428416,10788.05 > > 2010-09-29,10857.98,10901.96,10759.75,10835.28,399028,10835.28 > > 2010-09-28,10809.85,10905.44,10714.03,10858.14,402584,10858.14 > > 2010-09-27,10860.03,10902.52,10776.44,10812.04,358786,10812.04 > > 2010-09-24,10664.39,10897.83,10664.39,10860.26,412395,10860.26 > > 2010-09-23,10738.48,10779.65,10610.12,10662.42,384785,10662.42 > > 2010-09-22,10761.11,10829.75,10682.40,10739.31,391107,10739.31 > > 2010-09-21,10753.39,10844.89,10674.83,10761.03,417566,10761.03 > > 2010-09-20,10608.08,10783.51,10594.38,10753.62,336408,10753.62 > > > > > > > > > > On 25.09.2015 19:58, stepharo wrote: > >> Thanks for spotting this problem. > >> > >> > >> Le 21/9/15 11:33, Volkert a écrit : > >>> Switching the socket implementation works ... > >>> > >>> $./pharo Pharo.image eval "ZnNetworkingUtils default > socketStreamClass: SocketStream. ' > http://bl.ocks.org/mbostock/raw/4063318/dji.csv' asUrl retrieveContents" > >>> 'Date,Open,High,Low,Close,Volume,Adj Close > >>> 2010-10-01,10789.72,10907.41,10759.14,10829.68,429891,10829.68 > >>> 2010-09-30,10835.96,10960.99,10732.27,10788.05,428416,10788.05 > >>> 2010-09-29,10857.98,10901.96,10759.75,10835.28,399028,10835.28 > >>> 2010-09-28,10809.85,10905.44,10714.03,10858.14,402584,10858.14 > >>> 2010-09-27,10860.03,10902.52,10776.44,10812.04,358786,10812.04 > >>> > >>> > >>> > >>> The dedault implementation not ... > >>> > >>> $ ./pharo Pharo.image eval "' > http://bl.ocks.org/mbostock/raw/4063318/dji.csv' asUrl > retrieveContents" Startup Error: ConnectionClosed: Connection closed > while waiting for data. > >>> [ ConnectionClosed signal: 'Connection closed while waiting for data.' > ] in Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: > 'Connection closed whil...etc... > >>> Socket>>waitForDataFor:ifClosed:ifTimedOut: > >>> Socket>>waitForDataFor: > >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketWaitForData > >>> ZdcSocketStream>>readInto:startingAt:count: > >>> ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: > >>> ZnUTF8Encoder>>readInto:startingAt:count:fromStream: > >>> [ > >>> read := encoder > >>>readInto: buffer > >>>startingAt: 1 > >>>count: buffer size > >>>fromStream: readStream ] in ZnStringEntity>>readFrom: in Block: [ > ... > >>> BlockClosure>>on:do: > >>> ZnStringEntity>>readFrom: > >>> ZnEntity class>>readFrom:usingType:andLength: > >>> ZnEntityReader>>readFrom:usingType:andLength: > >>> ZnEntityReader>>readEntityFromStream > >>> [ entity := self readEntityFromStream ] in ZnEntityReader>>readEntity > in Block: [ entity := self readEntityFromStream ] > >>> [ > >>> p psValueAt: index put: anObject. > >>> aBlock value ] in > ZnDefaultCharacterEncoder(DynamicVariable)>>value:during: in Block: [ ... > >>> BlockClosure>>ensure: > >>> ZnDefaultCharacterEncoder(DynamicVariable)>>value:during: > >>> ZnDefaultCharacterEncoder class(DynamicVariable class)>>value:during: > >>> ZnEntityReader>>withDefaultUtf8Decoding: > >>> ZnEntityReader>>readEntity > >>> ZnResponse(ZnMessage)>>readEntityFrom: > >>> ZnResponse>>readEntityFrom: > >>> ZnResponse(ZnMessage)>>readFrom: > >>> ZnResponse class(ZnMessage class)>>readFrom: > >>> ZnClient>>readResponse > >>> ZnClient>>executeRequestResponse > >>> [ self executeRequestResponse ] in ZnClient>>getConnectionAndExecute > in Block: [ self executeRequestResponse ] > >>> BlockClosure>>ensure: > >>> ZnClient>>getConnectionAndExecute > >>> ZnClient>>executeWithRedirectsRemaining: > >>> Got startup errors: > >>>ConnectionClosed: Connection closed while waiting for data. > >>> > >>> Volkert > >>> > >>> > >>> > >>> On 21.09.2015 12:07, Sven Van Caekenberghe wrote: > > On 21 Sep 2015, at 11:45, Andrei Chis > wrote: > > > > So adding #beOneShot on some networks that are behind proxies, fails > the request. > Well, I was already afraid that (possibly transparent) proxies were > involved. > > The problem is, it is simply impossible for me to debug this remotely. > > One things that you could try is switching the socket stream > implementation used by Zn, > > ZnNetworkingUtils default socketStreamClass: SocketStream. > > to n
Re: [Pharo-users] Pharo 5 update of Grafeo
Yes, quite a cool toolkit. Thierry 2015-09-30 10:05 GMT+02:00 Alexandre Bergel : > Wow! > > Cool! > > Alexandre > > > On Sep 30, 2015, at 10:02 AM, Stephan Eggermont > wrote: > > > > Grafeo is a nice Morphic graph editing toolkit by Eiichiro Ito. > > It forms the basis for Fluo. > > https://vimeo.com/80749341 > > > > I've updated it for Pharo 5. I had to copy it to > > StephanEggermont/Documentation, as oohito/Fluo is not writable. > > > > Stephan > > > > > > Name: Grafeo-StephanEggermont.64 > > Author: StephanEggermont > > Time: 30 September 2015, 9:51:53.670434 am > > UUID: 5dc871e7-c1ea-4098-95c2-6c5741548ecb > > Ancestors: Grafeo-EiichiroIto.63 > > > > Changes for Pharo 5.0 > > Replaced deprecated menu methods > > Fixed one error message > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >
Re: [Pharo-users] Pharo 5 update of Grafeo
Wow! Cool! Alexandre > On Sep 30, 2015, at 10:02 AM, Stephan Eggermont wrote: > > Grafeo is a nice Morphic graph editing toolkit by Eiichiro Ito. > It forms the basis for Fluo. > https://vimeo.com/80749341 > > I've updated it for Pharo 5. I had to copy it to > StephanEggermont/Documentation, as oohito/Fluo is not writable. > > Stephan > > > Name: Grafeo-StephanEggermont.64 > Author: StephanEggermont > Time: 30 September 2015, 9:51:53.670434 am > UUID: 5dc871e7-c1ea-4098-95c2-6c5741548ecb > Ancestors: Grafeo-EiichiroIto.63 > > Changes for Pharo 5.0 > Replaced deprecated menu methods > Fixed one error message > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Pharo-users] Pharo 5 update of Grafeo
Grafeo is a nice Morphic graph editing toolkit by Eiichiro Ito. It forms the basis for Fluo. https://vimeo.com/80749341 I've updated it for Pharo 5. I had to copy it to StephanEggermont/Documentation, as oohito/Fluo is not writable. Stephan Name: Grafeo-StephanEggermont.64 Author: StephanEggermont Time: 30 September 2015, 9:51:53.670434 am UUID: 5dc871e7-c1ea-4098-95c2-6c5741548ecb Ancestors: Grafeo-EiichiroIto.63 Changes for Pharo 5.0 Replaced deprecated menu methods Fixed one error message
Re: [Pharo-users] Zn / Connection closed while waiting for data
> On 30 Sep 2015, at 08:16, Volkert wrote: > > For your information: today i tried again and know it works as expected ... OK, thanks for letting us know. > Same net > Same pharo-vm/image > Same ubuntu/kernel > > Strange maybe the "blood moon" on monday ... Yes, weird. > $ ./pharo Pharo.image eval "'http://bl.ocks.org/ostock/raw/4063318/dji.csv' > asUrl retrieveContents" > 'Date,Open,High,Low,Close,Volume,Adj Close > 2010-10-01,10789.72,10907.41,10759.14,10829.68,429891,10829.68 > 2010-09-30,10835.96,10960.99,10732.27,10788.05,428416,10788.05 > 2010-09-29,10857.98,10901.96,10759.75,10835.28,399028,10835.28 > 2010-09-28,10809.85,10905.44,10714.03,10858.14,402584,10858.14 > 2010-09-27,10860.03,10902.52,10776.44,10812.04,358786,10812.04 > 2010-09-24,10664.39,10897.83,10664.39,10860.26,412395,10860.26 > 2010-09-23,10738.48,10779.65,10610.12,10662.42,384785,10662.42 > 2010-09-22,10761.11,10829.75,10682.40,10739.31,391107,10739.31 > 2010-09-21,10753.39,10844.89,10674.83,10761.03,417566,10761.03 > 2010-09-20,10608.08,10783.51,10594.38,10753.62,336408,10753.62 > > > > > On 25.09.2015 19:58, stepharo wrote: >> Thanks for spotting this problem. >> >> >> Le 21/9/15 11:33, Volkert a écrit : >>> Switching the socket implementation works ... >>> >>> $./pharo Pharo.image eval "ZnNetworkingUtils default socketStreamClass: >>> SocketStream. 'http://bl.ocks.org/mbostock/raw/4063318/dji.csv' asUrl >>> retrieveContents" >>> 'Date,Open,High,Low,Close,Volume,Adj Close >>> 2010-10-01,10789.72,10907.41,10759.14,10829.68,429891,10829.68 >>> 2010-09-30,10835.96,10960.99,10732.27,10788.05,428416,10788.05 >>> 2010-09-29,10857.98,10901.96,10759.75,10835.28,399028,10835.28 >>> 2010-09-28,10809.85,10905.44,10714.03,10858.14,402584,10858.14 >>> 2010-09-27,10860.03,10902.52,10776.44,10812.04,358786,10812.04 >>> >>> >>> >>> The dedault implementation not ... >>> >>> $ ./pharo Pharo.image eval >>> "'http://bl.ocks.org/mbostock/raw/4063318/dji.csv' asUrl >>> retrieveContents" Startup Error: ConnectionClosed: Connection closed >>> while waiting for data. >>> [ ConnectionClosed signal: 'Connection closed while waiting for data.' ] in >>> Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: 'Connection >>> closed whil...etc... >>> Socket>>waitForDataFor:ifClosed:ifTimedOut: >>> Socket>>waitForDataFor: >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketWaitForData >>> ZdcSocketStream>>readInto:startingAt:count: >>> ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: >>> ZnUTF8Encoder>>readInto:startingAt:count:fromStream: >>> [ >>> read := encoder >>>readInto: buffer >>>startingAt: 1 >>>count: buffer size >>>fromStream: readStream ] in ZnStringEntity>>readFrom: in Block: [ ... >>> BlockClosure>>on:do: >>> ZnStringEntity>>readFrom: >>> ZnEntity class>>readFrom:usingType:andLength: >>> ZnEntityReader>>readFrom:usingType:andLength: >>> ZnEntityReader>>readEntityFromStream >>> [ entity := self readEntityFromStream ] in ZnEntityReader>>readEntity in >>> Block: [ entity := self readEntityFromStream ] >>> [ >>> p psValueAt: index put: anObject. >>> aBlock value ] in ZnDefaultCharacterEncoder(DynamicVariable)>>value:during: >>> in Block: [ ... >>> BlockClosure>>ensure: >>> ZnDefaultCharacterEncoder(DynamicVariable)>>value:during: >>> ZnDefaultCharacterEncoder class(DynamicVariable class)>>value:during: >>> ZnEntityReader>>withDefaultUtf8Decoding: >>> ZnEntityReader>>readEntity >>> ZnResponse(ZnMessage)>>readEntityFrom: >>> ZnResponse>>readEntityFrom: >>> ZnResponse(ZnMessage)>>readFrom: >>> ZnResponse class(ZnMessage class)>>readFrom: >>> ZnClient>>readResponse >>> ZnClient>>executeRequestResponse >>> [ self executeRequestResponse ] in ZnClient>>getConnectionAndExecute in >>> Block: [ self executeRequestResponse ] >>> BlockClosure>>ensure: >>> ZnClient>>getConnectionAndExecute >>> ZnClient>>executeWithRedirectsRemaining: >>> Got startup errors: >>>ConnectionClosed: Connection closed while waiting for data. >>> >>> Volkert >>> >>> >>> >>> On 21.09.2015 12:07, Sven Van Caekenberghe wrote: > On 21 Sep 2015, at 11:45, Andrei Chis wrote: > > So adding #beOneShot on some networks that are behind proxies, fails the > request. Well, I was already afraid that (possibly transparent) proxies were involved. The problem is, it is simply impossible for me to debug this remotely. One things that you could try is switching the socket stream implementation used by Zn, ZnNetworkingUtils default socketStreamClass: SocketStream. to no longer use ZdcSocketStream. Sven PS: Note that this is global setting >>> >>> >>> >> >> > >
