[Pharo-users] ZnClient - receiving/parsing malformed cookie 'expires' value

[PAUL DEBRUICKER]

Hi -  This is more of an FYI than anything


I'm interacting with an API that is sending "expires=0" value as part of the 
only cookie of their response.  


Changing  #expiresTimeStamp to 


(self expires isNil or:[self expires size<28] ) ifTrue:[ ^ DateAndTime now + 1 
day ].
^ ZnUtils parseHttpDate: self expires


fixes my issue but maybe there's a better way to handle cookie parsing errors 


Paul

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

[Sean P. DeNigris]

Guillermo Polito wrote
> I've done also some profiling and it does not look like we've lost in
> performance either (reading and decoding a 35MB file):

Your 1st (new API) example: "0:00:00:01.535"
Your 2nd (old API) example:"0:00:00:01.732"
*** but ***
Your 1st (new API) example using the same consuming selector as example #1
(#upToEnd): "0:00:00:07.816" or 4.5x slower



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] MiniScheme in Pharo

[Stephane Ducasse]

Clement I added a little section right at the beginning on car/cdr and others.

Tx

On Sun, Mar 18, 2018 at 11:32 AM, Clément Bera  wrote:
> p.3
> simpliciyty -> simplicity
>
> p.4
> we will have the define their semantics.
> -> to define ? I am not sure I understand the sentence
>
> p.10
> and may converted on the fly
> -> and maybe ? I am not sure I understand the sentence
>
> At the beginning I started to read and understood nothing, then I read a 24
> slides lecture on lisp lists [1], then I restarted to read and understood
> One of my main problem was that what cdr does is explained p.7, while cdr is
> used p.3 for the first time and multiple times before p.7. But maybe you
> expect the reader to know scheme already.
>
> [1] https://perso.liris.cnrs.fr/nathalie.guin/LIF3/Cours/Cours3-Listes.pdf
> (first result on google for me)
>
> On Sat, Mar 17, 2018 at 7:36 PM, Stephane Ducasse 
> wrote:
>>
>> Hi
>>
>> I finally decided to release the booklet I wrote about implementing a
>> minischeme in Pharo.
>> I did not announce it yet because I would like to get feedback and fix
>> what can be fixed.
>>
>>
>>
>> https://files.pharo.org/books-pdfs/booklet-AMiniSchemeInPharo/2018-03-17-MiniScheme.pdf
>>
>> Stef
>>
>
>
>
> --
> Clément Béra
> https://clementbera.github.io/
> https://clementbera.wordpress.com/

Re: [Pharo-users] MiniScheme in Pharo

[Stephane Ducasse]

Since I was born in lisp it looks natural to me so I will imporve the cdr use

tx for this feedback


On Sun, Mar 18, 2018 at 11:32 AM, Clément Bera  wrote:
> p.3
> simpliciyty -> simplicity
>
> p.4
> we will have the define their semantics.
> -> to define ? I am not sure I understand the sentence
>
> p.10
> and may converted on the fly
> -> and maybe ? I am not sure I understand the sentence
>
> At the beginning I started to read and understood nothing, then I read a 24
> slides lecture on lisp lists [1], then I restarted to read and understood
> One of my main problem was that what cdr does is explained p.7, while cdr is
> used p.3 for the first time and multiple times before p.7. But maybe you
> expect the reader to know scheme already.
>
> [1] https://perso.liris.cnrs.fr/nathalie.guin/LIF3/Cours/Cours3-Listes.pdf
> (first result on google for me)
>
> On Sat, Mar 17, 2018 at 7:36 PM, Stephane Ducasse 
> wrote:
>>
>> Hi
>>
>> I finally decided to release the booklet I wrote about implementing a
>> minischeme in Pharo.
>> I did not announce it yet because I would like to get feedback and fix
>> what can be fixed.
>>
>>
>>
>> https://files.pharo.org/books-pdfs/booklet-AMiniSchemeInPharo/2018-03-17-MiniScheme.pdf
>>
>> Stef
>>
>
>
>
> --
> Clément Béra
> https://clementbera.github.io/
> https://clementbera.wordpress.com/

Re: [Pharo-users] MiniScheme in Pharo

[Stephane Ducasse]

Yes there!

Tx in advance for copy edition.

Stef

On Sun, Mar 18, 2018 at 4:59 PM, Cyril Ferlicot
 wrote:
>
> On dim. 18 mars 2018 at 16:24, Sean P. DeNigris 
> wrote:
>>
>> Stephane Ducasse-3 wrote
>> > I would like to get feedback and fix
>> > what can be fixed.
>>
>> Is there a public link to the source? It would be easiest to submit fixes
>> via PRs instead of ML :)
>>
>
> Probably
>
> https://github.com/SquareBracketAssociates/Booklet-AMiniSchemeInPharo
>
>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
> --
> Cyril Ferlicot
> https://ferlicot.fr

Re: [Pharo-users] inquiring question about ifTrue: implementation

[Stephane Ducasse]

+ 1

:)

On Mon, Mar 19, 2018 at 2:16 PM, Petr Fischer  wrote:
> That sounds correct. In this context, my "universal ifTrue:" is really 
> terrible idea.
>
> Thanks for clarification! pf
>
>
>> Why would you do such aberration?
>>
>> It goes against the "fail noisily" "Rule of Repair": Developers should
>> design programs that fail in a manner that is easy to localize and
>> diagnose or in other words “fail noisily”. This rule aims to prevent
>> incorrect output from a program from becoming an input and corrupting
>> the output of other code undetected.
>>
>> It is semantically incorrect, if needed, I don't see why, you sould
>> implement it in  your own class. But when I needed to do such "if"
>> handlers, I did it using meaningful selectors like #ifGranted: or
>> #ifSucceeded:, or the well known #ifEmpty:
>>
>> Regards,
>>
>> Esteban A. Maringolo
>>
>>
>> 2018-03-19 9:40 GMT-03:00 Petr Fischer :
>> >> Infinite recursion ?
>> >>
>> >> You use #ifTrue: in your implementation of Object>>#ifTrue:
>> >>
>> >> Plus, non-booleans cannot meaningfully respond.
>> >>
>> >> How would you define the semantics of
>> >>
>> >> 123 ifTrue: [ ... ]
>> >
>> > 123 is not "true", so, ignore the block.
>> > Do the ifTrue block only if the receiver is instance of True (true). 
>> > Everything else is not "true" :)
>> >
>> > I missed the recursion, yes, but it could be done another way.
>> >
>> >>
>> >> > On 19 Mar 2018, at 10:18, Petr Fischer  wrote:
>> >> >
>> >> > Hello, I have some sort of philosophical question about 
>> >> > ifTrue:/ifFalse: implementation.
>> >> >
>> >> > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + 
>> >> > in True and False classes, so, we can send this message to the boolean 
>> >> > expressions (instances) only, otherwise DND occurs.
>> >> >
>> >> > But we can also define one universal ifTrue: right in the Object class, 
>> >> > in this style:
>> >> >
>> >> > Object>>ifTrue: 
>> >> > (self = true) ifTrue: [ ... ].
>> >> >
>> >> > then, we can send ifTrue: message to ANY object and it will work 
>> >> > correctly without DND exception on non-boolean objects.
>> >> >
>> >> > Is something bad about this idea?
>> >> >
>> >> > Thanks! pf
>> >> >
>> >>
>> >>
>> >
>>
>

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

[Stephane Ducasse]

I love the idea of measuring statement :)


On Mon, Mar 19, 2018 at 6:10 PM, Guillermo Polito  wrote:

> Well, I'd say it we did it in the name of modularity. And yes, I believe
> that having separate responsibilities help in designing, testing and
> ensuring more easily the correctness of each of the parts in isolation.
>
> I've done also some profiling and it does not look like we've lost in
> performance either (reading and decoding a 35MB file):
>
> [file := Smalltalk sourcesFile fullName.
> (File named: file) readStreamDo: [ :binaryFile |
> (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding:
> 'utf8') next: binaryFile size.
> ]] timeToRun. "0:00:00:01.976"
>
> [file := Smalltalk sourcesFile fullName.
> (MultiByteFileStream fileNamed: file)
> converter: (TextConverter newForEncoding: 'utf8');
> upToEnd
> ] timeToRun. "0:00:00:02.147"
>
>
>
> On Mon, Mar 19, 2018 at 5:51 PM, Richard O'Keefe  wrote:
>
>> The idea of stacking things like character coding and buffering 
>> by using layers of wrapping is very much in the spirit of Java and
>> is neither good for performance nor helpful for correctness.
>>
>>
>> On 20 March 2018 at 05:19, Guillermo Polito 
>> wrote:
>>
>>> Hi all,
>>>
>>> I've put some minutes summarizing the new APIs provided by the
>>> combination of the new File implementation and the Zn encoders. They all
>>> basically follow the decorator pattern to stack different responsibilities
>>> such as buffering, encoding, line ending convertions.
>>>
>>> Please, do not hesitate to give your feedback.
>>>
>>> Guille
>>>
>>>
>>> 1. Basic Files
>>>
>>> By default files are binary. Not buffered.
>>>
>>> (File named: 'name') readStream.
>>> (File named: 'name') readStreamDo: [ :stream | ... ].
>>> (File named: 'name') writeStream.
>>> (File named: 'name') writeStreamDo: [ :stream | ... ].
>>>
>>>
>>> 2. Encoding
>>>
>>> To add encoding, wrap a stream with a corresponding
>>> ZnCharacterRead/WriteStream.
>>>
>>> "Reading"
>>> utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'.
>>> utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding:
>>> 'utf16'.
>>>
>>> "Writing"
>>> utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'.
>>> utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding:
>>> 'utf16'.
>>>
>>> 3. Buffering
>>>
>>> To add buffering, wrap a stream with a corresponding
>>> ZnBufferedRead/WriteStream.
>>>
>>> bufferedReadStream := ZnBufferedReadStream on: aStream.
>>> bufferedWriteStream := ZnBufferedWriteStream on: aStream.
>>>
>>> It is in general better to buffer the reading on the binary file and
>>> apply the encoding on the buffer in memory than the other way around. See
>>>
>>> [file := Smalltalk sourcesFile fullName.
>>> (File named: file) readStreamDo: [ :binaryFile |
>>> (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile)
>>> encoding: 'utf8') upToEnd
>>> ]] timeToRun. "0:00:00:09.288"
>>>
>>> [file := Smalltalk sourcesFile fullName.
>>> (File named: file) readStreamDo: [ :binaryFile |
>>> (ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile
>>> encoding: 'utf8')) upToEnd
>>> ]] timeToRun. "0:00:00:14.189"
>>>
>>> 4. File System
>>>
>>> By default, file system files are buffered and utf8 encoded to keep
>>> backwards compatibility.
>>>
>>> 'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ].
>>> 'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ].
>>>
>>> FileStream also provides access to plain binary files using the
>>> #binaryRead/WriteStream messages. Binary streams are buffered by default
>>> also.
>>>
>>> 'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ...
>>> ].
>>> 'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream |
>>> ... ].
>>>
>>> If you want a file with another encoding (to come in the PR
>>> https://github.com/pharo-project/pharo/pull/1134), you can specify it
>>> while obtaining the stream:
>>>
>>> 'name' asFileReference
>>> readStreamEncoded: 'utf16'
>>> do: [ :bufferedUtf16Stream | ... ].
>>>
>>> 'name' asFileReference
>>> writeStreamEncoded: 'utf8'
>>> do: [ :bufferedUtf16Stream | ... ].
>>>
>>> 5. Line Ending Conventions
>>>
>>> If you want to write files following a specific line ending convention,
>>> use the ZnNewLineWriterStream.
>>> This stream decorator will transform any line ending (cr, lf, crlf) into
>>> a defined line ending.
>>> By default it chooses the platform line ending convention.
>>>
>>> lineWriter := ZnNewLineWriterStream on: aStream.
>>>
>>> If you want to choose another line ending convention you can do:
>>>
>>> lineWriter forCr.
>>> lineWriter forLf.
>>> lineWriter forCrLf.
>>> lineWriter forPlatformLineEnding.
>>>
>>> --
>>>
>>>
>>>
>>> Guille Polito
>>>
>>> Research Engineer
>>>
>>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>>
>>> CRIStAL - UMR 9189
>>>

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

[Stephane Ducasse]

Thanks Guille for this great post!
I will turn it into a doc :)



On Mon, Mar 19, 2018 at 6:10 PM, Guillermo Polito  wrote:

> Well, I'd say it we did it in the name of modularity. And yes, I believe
> that having separate responsibilities help in designing, testing and
> ensuring more easily the correctness of each of the parts in isolation.
>
> I've done also some profiling and it does not look like we've lost in
> performance either (reading and decoding a 35MB file):
>
> [file := Smalltalk sourcesFile fullName.
> (File named: file) readStreamDo: [ :binaryFile |
> (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding:
> 'utf8') next: binaryFile size.
> ]] timeToRun. "0:00:00:01.976"
>
> [file := Smalltalk sourcesFile fullName.
> (MultiByteFileStream fileNamed: file)
> converter: (TextConverter newForEncoding: 'utf8');
> upToEnd
> ] timeToRun. "0:00:00:02.147"
>
>
>
> On Mon, Mar 19, 2018 at 5:51 PM, Richard O'Keefe  wrote:
>
>> The idea of stacking things like character coding and buffering 
>> by using layers of wrapping is very much in the spirit of Java and
>> is neither good for performance nor helpful for correctness.
>>
>>
>> On 20 March 2018 at 05:19, Guillermo Polito 
>> wrote:
>>
>>> Hi all,
>>>
>>> I've put some minutes summarizing the new APIs provided by the
>>> combination of the new File implementation and the Zn encoders. They all
>>> basically follow the decorator pattern to stack different responsibilities
>>> such as buffering, encoding, line ending convertions.
>>>
>>> Please, do not hesitate to give your feedback.
>>>
>>> Guille
>>>
>>>
>>> 1. Basic Files
>>>
>>> By default files are binary. Not buffered.
>>>
>>> (File named: 'name') readStream.
>>> (File named: 'name') readStreamDo: [ :stream | ... ].
>>> (File named: 'name') writeStream.
>>> (File named: 'name') writeStreamDo: [ :stream | ... ].
>>>
>>>
>>> 2. Encoding
>>>
>>> To add encoding, wrap a stream with a corresponding
>>> ZnCharacterRead/WriteStream.
>>>
>>> "Reading"
>>> utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'.
>>> utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding:
>>> 'utf16'.
>>>
>>> "Writing"
>>> utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'.
>>> utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding:
>>> 'utf16'.
>>>
>>> 3. Buffering
>>>
>>> To add buffering, wrap a stream with a corresponding
>>> ZnBufferedRead/WriteStream.
>>>
>>> bufferedReadStream := ZnBufferedReadStream on: aStream.
>>> bufferedWriteStream := ZnBufferedWriteStream on: aStream.
>>>
>>> It is in general better to buffer the reading on the binary file and
>>> apply the encoding on the buffer in memory than the other way around. See
>>>
>>> [file := Smalltalk sourcesFile fullName.
>>> (File named: file) readStreamDo: [ :binaryFile |
>>> (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile)
>>> encoding: 'utf8') upToEnd
>>> ]] timeToRun. "0:00:00:09.288"
>>>
>>> [file := Smalltalk sourcesFile fullName.
>>> (File named: file) readStreamDo: [ :binaryFile |
>>> (ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile
>>> encoding: 'utf8')) upToEnd
>>> ]] timeToRun. "0:00:00:14.189"
>>>
>>> 4. File System
>>>
>>> By default, file system files are buffered and utf8 encoded to keep
>>> backwards compatibility.
>>>
>>> 'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ].
>>> 'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ].
>>>
>>> FileStream also provides access to plain binary files using the
>>> #binaryRead/WriteStream messages. Binary streams are buffered by default
>>> also.
>>>
>>> 'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ...
>>> ].
>>> 'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream |
>>> ... ].
>>>
>>> If you want a file with another encoding (to come in the PR
>>> https://github.com/pharo-project/pharo/pull/1134), you can specify it
>>> while obtaining the stream:
>>>
>>> 'name' asFileReference
>>> readStreamEncoded: 'utf16'
>>> do: [ :bufferedUtf16Stream | ... ].
>>>
>>> 'name' asFileReference
>>> writeStreamEncoded: 'utf8'
>>> do: [ :bufferedUtf16Stream | ... ].
>>>
>>> 5. Line Ending Conventions
>>>
>>> If you want to write files following a specific line ending convention,
>>> use the ZnNewLineWriterStream.
>>> This stream decorator will transform any line ending (cr, lf, crlf) into
>>> a defined line ending.
>>> By default it chooses the platform line ending convention.
>>>
>>> lineWriter := ZnNewLineWriterStream on: aStream.
>>>
>>> If you want to choose another line ending convention you can do:
>>>
>>> lineWriter forCr.
>>> lineWriter forLf.
>>> lineWriter forCrLf.
>>> lineWriter forPlatformLineEnding.
>>>
>>> --
>>>
>>>
>>>
>>> Guille Polito
>>>
>>> Research Engineer
>>>
>>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>>
>>> 

Re: [Pharo-users] Pharo sound with SDL Library

[Stephane Ducasse]

Yes we should migrate it and probably include it in Pharo and clean it.

Stef

On Mon, Mar 19, 2018 at 6:59 PM, Mariano Badoglio
 wrote:
> Hi Stephean, Sean,
>
> Thanks for your response. I have installed the Monticello Package
> "Sound" from http://smalltalkhub.com/mc/PharoExtras/Sound/main, the last
> update is Sound-StephaneDucasse.80 package from year 2013. It is from
> Pharo Extras. Is this the right package?
>
> Best regards,
> Mariano
>
>
> El 17/03/18 a las 16:05, Stephane Ducasse escribió:
>> Hi mariano
>>
>> did you try the sound package that is on Smalltalkhub/Pharo? or
>> PharoExtras. We should migrate it to pharo 70
>>
>> Stef
>>
>> On Sat, Mar 17, 2018 at 1:14 PM, Mariano Badoglio
>>  wrote:
>>> Hello!
>>>
>>> I need to use the Pharo Sound over Ubuntu platform, but I couldn't get
>>> it work. I tryied sending the parameter vm-sound-OSS and vm-sound-ALSA
>>> to the vm but I get no results.
>>>
>>> I am now trying to use the SDL Library. I could initialize the sound
>>> SDL_Init(SDL_INIT_AUDIO), very similar to initializing video, but when
>>> trying to use the SDL_LoadWAV, it needs a SDL_AudioSpec data type and I
>>> do not know how to do it. I tried to use an Structure as parameter but
>>> with no result, I couldn't found any similar example to follow. I will
>>> appreciate any help or tips on this.
>>>
>>> Thanks in advance. Best regards,
>>> Mariano.
>>>
>>>
>>>
>>
>
>

[Pharo-users] HRWorks is looking for Pharoers :)

[Stephane Ducasse]

https://www.hrworks.de/en/international-applicants/

Stef

Re: [Pharo-users] Pharo sound with SDL Library

[Mariano Badoglio]

Hi Stephean, Sean,

Thanks for your response. I have installed the Monticello Package
"Sound" from http://smalltalkhub.com/mc/PharoExtras/Sound/main, the last
update is Sound-StephaneDucasse.80 package from year 2013. It is from
Pharo Extras. Is this the right package?

Best regards,
Mariano


El 17/03/18 a las 16:05, Stephane Ducasse escribió:
> Hi mariano
>
> did you try the sound package that is on Smalltalkhub/Pharo? or
> PharoExtras. We should migrate it to pharo 70
>
> Stef
>
> On Sat, Mar 17, 2018 at 1:14 PM, Mariano Badoglio
>  wrote:
>> Hello!
>>
>> I need to use the Pharo Sound over Ubuntu platform, but I couldn't get
>> it work. I tryied sending the parameter vm-sound-OSS and vm-sound-ALSA
>> to the vm but I get no results.
>>
>> I am now trying to use the SDL Library. I could initialize the sound
>> SDL_Init(SDL_INIT_AUDIO), very similar to initializing video, but when
>> trying to use the SDL_LoadWAV, it needs a SDL_AudioSpec data type and I
>> do not know how to do it. I tried to use an Structure as parameter but
>> with no result, I couldn't found any similar example to follow. I will
>> appreciate any help or tips on this.
>>
>> Thanks in advance. Best regards,
>> Mariano.
>>
>>
>>
>

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

[Guillermo Polito]

Well, I'd say it we did it in the name of modularity. And yes, I believe
that having separate responsibilities help in designing, testing and
ensuring more easily the correctness of each of the parts in isolation.

I've done also some profiling and it does not look like we've lost in
performance either (reading and decoding a 35MB file):

[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding:
'utf8') next: binaryFile size.
]] timeToRun. "0:00:00:01.976"

[file := Smalltalk sourcesFile fullName.
(MultiByteFileStream fileNamed: file)
converter: (TextConverter newForEncoding: 'utf8');
upToEnd
] timeToRun. "0:00:00:02.147"



On Mon, Mar 19, 2018 at 5:51 PM, Richard O'Keefe  wrote:

> The idea of stacking things like character coding and buffering 
> by using layers of wrapping is very much in the spirit of Java and
> is neither good for performance nor helpful for correctness.
>
>
> On 20 March 2018 at 05:19, Guillermo Polito 
> wrote:
>
>> Hi all,
>>
>> I've put some minutes summarizing the new APIs provided by the
>> combination of the new File implementation and the Zn encoders. They all
>> basically follow the decorator pattern to stack different responsibilities
>> such as buffering, encoding, line ending convertions.
>>
>> Please, do not hesitate to give your feedback.
>>
>> Guille
>>
>>
>> 1. Basic Files
>>
>> By default files are binary. Not buffered.
>>
>> (File named: 'name') readStream.
>> (File named: 'name') readStreamDo: [ :stream | ... ].
>> (File named: 'name') writeStream.
>> (File named: 'name') writeStreamDo: [ :stream | ... ].
>>
>>
>> 2. Encoding
>>
>> To add encoding, wrap a stream with a corresponding
>> ZnCharacterRead/WriteStream.
>>
>> "Reading"
>> utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'.
>> utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf16'.
>>
>> "Writing"
>> utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'.
>> utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding:
>> 'utf16'.
>>
>> 3. Buffering
>>
>> To add buffering, wrap a stream with a corresponding
>> ZnBufferedRead/WriteStream.
>>
>> bufferedReadStream := ZnBufferedReadStream on: aStream.
>> bufferedWriteStream := ZnBufferedWriteStream on: aStream.
>>
>> It is in general better to buffer the reading on the binary file and
>> apply the encoding on the buffer in memory than the other way around. See
>>
>> [file := Smalltalk sourcesFile fullName.
>> (File named: file) readStreamDo: [ :binaryFile |
>> (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile)
>> encoding: 'utf8') upToEnd
>> ]] timeToRun. "0:00:00:09.288"
>>
>> [file := Smalltalk sourcesFile fullName.
>> (File named: file) readStreamDo: [ :binaryFile |
>> (ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding:
>> 'utf8')) upToEnd
>> ]] timeToRun. "0:00:00:14.189"
>>
>> 4. File System
>>
>> By default, file system files are buffered and utf8 encoded to keep
>> backwards compatibility.
>>
>> 'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ].
>> 'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ].
>>
>> FileStream also provides access to plain binary files using the
>> #binaryRead/WriteStream messages. Binary streams are buffered by default
>> also.
>>
>> 'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ...
>> ].
>> 'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | ...
>> ].
>>
>> If you want a file with another encoding (to come in the PR
>> https://github.com/pharo-project/pharo/pull/1134), you can specify it
>> while obtaining the stream:
>>
>> 'name' asFileReference
>> readStreamEncoded: 'utf16'
>> do: [ :bufferedUtf16Stream | ... ].
>>
>> 'name' asFileReference
>> writeStreamEncoded: 'utf8'
>> do: [ :bufferedUtf16Stream | ... ].
>>
>> 5. Line Ending Conventions
>>
>> If you want to write files following a specific line ending convention,
>> use the ZnNewLineWriterStream.
>> This stream decorator will transform any line ending (cr, lf, crlf) into
>> a defined line ending.
>> By default it chooses the platform line ending convention.
>>
>> lineWriter := ZnNewLineWriterStream on: aStream.
>>
>> If you want to choose another line ending convention you can do:
>>
>> lineWriter forCr.
>> lineWriter forLf.
>> lineWriter forCrLf.
>> lineWriter forPlatformLineEnding.
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>> Research Engineer
>>
>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>
>> CRIStAL - UMR 9189
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr
>> *
>>
>>
>> *Web:* *http://guillep.github.io* 
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>


-- 



Guille Polito

Research Engineer

Centre de 

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

[Richard O'Keefe]

The idea of stacking things like character coding and buffering 
by using layers of wrapping is very much in the spirit of Java and
is neither good for performance nor helpful for correctness.


On 20 March 2018 at 05:19, Guillermo Polito 
wrote:

> Hi all,
>
> I've put some minutes summarizing the new APIs provided by the combination
> of the new File implementation and the Zn encoders. They all basically
> follow the decorator pattern to stack different responsibilities such as
> buffering, encoding, line ending convertions.
>
> Please, do not hesitate to give your feedback.
>
> Guille
>
>
> 1. Basic Files
>
> By default files are binary. Not buffered.
>
> (File named: 'name') readStream.
> (File named: 'name') readStreamDo: [ :stream | ... ].
> (File named: 'name') writeStream.
> (File named: 'name') writeStreamDo: [ :stream | ... ].
>
>
> 2. Encoding
>
> To add encoding, wrap a stream with a corresponding
> ZnCharacterRead/WriteStream.
>
> "Reading"
> utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'.
> utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf16'.
>
> "Writing"
> utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'.
> utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf16'.
>
> 3. Buffering
>
> To add buffering, wrap a stream with a corresponding
> ZnBufferedRead/WriteStream.
>
> bufferedReadStream := ZnBufferedReadStream on: aStream.
> bufferedWriteStream := ZnBufferedWriteStream on: aStream.
>
> It is in general better to buffer the reading on the binary file and apply
> the encoding on the buffer in memory than the other way around. See
>
> [file := Smalltalk sourcesFile fullName.
> (File named: file) readStreamDo: [ :binaryFile |
> (ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding:
> 'utf8') upToEnd
> ]] timeToRun. "0:00:00:09.288"
>
> [file := Smalltalk sourcesFile fullName.
> (File named: file) readStreamDo: [ :binaryFile |
> (ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding:
> 'utf8')) upToEnd
> ]] timeToRun. "0:00:00:14.189"
>
> 4. File System
>
> By default, file system files are buffered and utf8 encoded to keep
> backwards compatibility.
>
> 'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ].
> 'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ].
>
> FileStream also provides access to plain binary files using the
> #binaryRead/WriteStream messages. Binary streams are buffered by default
> also.
>
> 'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ... ].
> 'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | ...
> ].
>
> If you want a file with another encoding (to come in the PR
> https://github.com/pharo-project/pharo/pull/1134), you can specify it
> while obtaining the stream:
>
> 'name' asFileReference
> readStreamEncoded: 'utf16'
> do: [ :bufferedUtf16Stream | ... ].
>
> 'name' asFileReference
> writeStreamEncoded: 'utf8'
> do: [ :bufferedUtf16Stream | ... ].
>
> 5. Line Ending Conventions
>
> If you want to write files following a specific line ending convention,
> use the ZnNewLineWriterStream.
> This stream decorator will transform any line ending (cr, lf, crlf) into a
> defined line ending.
> By default it chooses the platform line ending convention.
>
> lineWriter := ZnNewLineWriterStream on: aStream.
>
> If you want to choose another line ending convention you can do:
>
> lineWriter forCr.
> lineWriter forLf.
> lineWriter forCrLf.
> lineWriter forPlatformLineEnding.
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

[Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

[Guillermo Polito]

Hi all,

I've put some minutes summarizing the new APIs provided by the combination
of the new File implementation and the Zn encoders. They all basically
follow the decorator pattern to stack different responsibilities such as
buffering, encoding, line ending convertions.

Please, do not hesitate to give your feedback.

Guille


1. Basic Files

By default files are binary. Not buffered.

(File named: 'name') readStream.
(File named: 'name') readStreamDo: [ :stream | ... ].
(File named: 'name') writeStream.
(File named: 'name') writeStreamDo: [ :stream | ... ].


2. Encoding

To add encoding, wrap a stream with a corresponding
ZnCharacterRead/WriteStream.

"Reading"
utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'.
utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf16'.

"Writing"
utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'.
utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf16'.

3. Buffering

To add buffering, wrap a stream with a corresponding
ZnBufferedRead/WriteStream.

bufferedReadStream := ZnBufferedReadStream on: aStream.
bufferedWriteStream := ZnBufferedWriteStream on: aStream.

It is in general better to buffer the reading on the binary file and apply
the encoding on the buffer in memory than the other way around. See

[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding:
'utf8') upToEnd
]] timeToRun. "0:00:00:09.288"

[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding:
'utf8')) upToEnd
]] timeToRun. "0:00:00:14.189"

4. File System

By default, file system files are buffered and utf8 encoded to keep
backwards compatibility.

'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ].
'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ].

FileStream also provides access to plain binary files using the
#binaryRead/WriteStream messages. Binary streams are buffered by default
also.

'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ... ].
'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | ... ].

If you want a file with another encoding (to come in the PR
https://github.com/pharo-project/pharo/pull/1134), you can specify it while
obtaining the stream:

'name' asFileReference
readStreamEncoded: 'utf16'
do: [ :bufferedUtf16Stream | ... ].

'name' asFileReference
writeStreamEncoded: 'utf8'
do: [ :bufferedUtf16Stream | ... ].

5. Line Ending Conventions

If you want to write files following a specific line ending convention, use
the ZnNewLineWriterStream.
This stream decorator will transform any line ending (cr, lf, crlf) into a
defined line ending.
By default it chooses the platform line ending convention.

lineWriter := ZnNewLineWriterStream on: aStream.

If you want to choose another line ending convention you can do:

lineWriter forCr.
lineWriter forLf.
lineWriter forCrLf.
lineWriter forPlatformLineEnding.

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] inquiring question about ifTrue: implementation

[Richard O'Keefe]

The idea in Smalltalk is to push a method as high as makes sense
and no higher, so that if you send a message to an object where it
really does not make sense (like trying to add two strings) you
get a runtime failure.  (Try asking an old-timer about automatic
conversions in PL/I some time.)  Now Lisp *did* define NIL=false,
anything else=true, and Lisp came before Smalltalk, and you can
bet the designers of Smalltalk knew about this possibility.

As a particular example, I seem to forget to initialise variables
embarrassingly often, and having x ifTrue: ... ifFalse: ... fail
noisily because x was still nil has made my life simpler too often.


On 20 March 2018 at 02:16, Petr Fischer  wrote:

> That sounds correct. In this context, my "universal ifTrue:" is really
> terrible idea.
>
> Thanks for clarification! pf
>
>
> > Why would you do such aberration?
> >
> > It goes against the "fail noisily" "Rule of Repair": Developers should
> > design programs that fail in a manner that is easy to localize and
> > diagnose or in other words “fail noisily”. This rule aims to prevent
> > incorrect output from a program from becoming an input and corrupting
> > the output of other code undetected.
> >
> > It is semantically incorrect, if needed, I don't see why, you sould
> > implement it in  your own class. But when I needed to do such "if"
> > handlers, I did it using meaningful selectors like #ifGranted: or
> > #ifSucceeded:, or the well known #ifEmpty:
> >
> > Regards,
> >
> > Esteban A. Maringolo
> >
> >
> > 2018-03-19 9:40 GMT-03:00 Petr Fischer :
> > >> Infinite recursion ?
> > >>
> > >> You use #ifTrue: in your implementation of Object>>#ifTrue:
> > >>
> > >> Plus, non-booleans cannot meaningfully respond.
> > >>
> > >> How would you define the semantics of
> > >>
> > >> 123 ifTrue: [ ... ]
> > >
> > > 123 is not "true", so, ignore the block.
> > > Do the ifTrue block only if the receiver is instance of True (true).
> Everything else is not "true" :)
> > >
> > > I missed the recursion, yes, but it could be done another way.
> > >
> > >>
> > >> > On 19 Mar 2018, at 10:18, Petr Fischer  wrote:
> > >> >
> > >> > Hello, I have some sort of philosophical question about
> ifTrue:/ifFalse: implementation.
> > >> >
> > >> > Now, ifTrue: is defined in the Boolean class
> (subclassResponsibility) + in True and False classes, so, we can send this
> message to the boolean expressions (instances) only, otherwise DND occurs.
> > >> >
> > >> > But we can also define one universal ifTrue: right in the Object
> class, in this style:
> > >> >
> > >> > Object>>ifTrue: 
> > >> > (self = true) ifTrue: [ ... ].
> > >> >
> > >> > then, we can send ifTrue: message to ANY object and it will work
> correctly without DND exception on non-boolean objects.
> > >> >
> > >> > Is something bad about this idea?
> > >> >
> > >> > Thanks! pf
> > >> >
> > >>
> > >>
> > >
> >
>
>

Re: [Pharo-users] inquiring question about ifTrue: implementation

[Petr Fischer]

That sounds correct. In this context, my "universal ifTrue:" is really terrible 
idea.

Thanks for clarification! pf


> Why would you do such aberration?
> 
> It goes against the "fail noisily" "Rule of Repair": Developers should
> design programs that fail in a manner that is easy to localize and
> diagnose or in other words “fail noisily”. This rule aims to prevent
> incorrect output from a program from becoming an input and corrupting
> the output of other code undetected.
> 
> It is semantically incorrect, if needed, I don't see why, you sould
> implement it in  your own class. But when I needed to do such "if"
> handlers, I did it using meaningful selectors like #ifGranted: or
> #ifSucceeded:, or the well known #ifEmpty:
> 
> Regards,
> 
> Esteban A. Maringolo
> 
> 
> 2018-03-19 9:40 GMT-03:00 Petr Fischer :
> >> Infinite recursion ?
> >>
> >> You use #ifTrue: in your implementation of Object>>#ifTrue:
> >>
> >> Plus, non-booleans cannot meaningfully respond.
> >>
> >> How would you define the semantics of
> >>
> >> 123 ifTrue: [ ... ]
> >
> > 123 is not "true", so, ignore the block.
> > Do the ifTrue block only if the receiver is instance of True (true). 
> > Everything else is not "true" :)
> >
> > I missed the recursion, yes, but it could be done another way.
> >
> >>
> >> > On 19 Mar 2018, at 10:18, Petr Fischer  wrote:
> >> >
> >> > Hello, I have some sort of philosophical question about ifTrue:/ifFalse: 
> >> > implementation.
> >> >
> >> > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + 
> >> > in True and False classes, so, we can send this message to the boolean 
> >> > expressions (instances) only, otherwise DND occurs.
> >> >
> >> > But we can also define one universal ifTrue: right in the Object class, 
> >> > in this style:
> >> >
> >> > Object>>ifTrue: 
> >> > (self = true) ifTrue: [ ... ].
> >> >
> >> > then, we can send ifTrue: message to ANY object and it will work 
> >> > correctly without DND exception on non-boolean objects.
> >> >
> >> > Is something bad about this idea?
> >> >
> >> > Thanks! pf
> >> >
> >>
> >>
> >
> 

Re: [Pharo-users] inquiring question about ifTrue: implementation

[Petr Fischer]

> On 19 March 2018 at 13:40, Petr Fischer  wrote:
> 
> > > How would you define the semantics of
> > >
> > > 123 ifTrue: [ ... ]
> >
> > 123 is not "true", so, ignore the block.
> >
> 
> What anout 123 ifFalse: [ … ], then, given that 123 is not false either?

Yes :) 123 is not false, so ignore the block again.

Esteban explained it to me via "fail noisily" and "Rule of Repair" in this 
thread.

Thanks! pf

Re: [Pharo-users] inquiring question about ifTrue: implementation

[Esteban A. Maringolo]

Why would you do such aberration?

It goes against the "fail noisily" "Rule of Repair": Developers should
design programs that fail in a manner that is easy to localize and
diagnose or in other words “fail noisily”. This rule aims to prevent
incorrect output from a program from becoming an input and corrupting
the output of other code undetected.

It is semantically incorrect, if needed, I don't see why, you sould
implement it in  your own class. But when I needed to do such "if"
handlers, I did it using meaningful selectors like #ifGranted: or
#ifSucceeded:, or the well known #ifEmpty:

Regards,

Esteban A. Maringolo


2018-03-19 9:40 GMT-03:00 Petr Fischer :
>> Infinite recursion ?
>>
>> You use #ifTrue: in your implementation of Object>>#ifTrue:
>>
>> Plus, non-booleans cannot meaningfully respond.
>>
>> How would you define the semantics of
>>
>> 123 ifTrue: [ ... ]
>
> 123 is not "true", so, ignore the block.
> Do the ifTrue block only if the receiver is instance of True (true). 
> Everything else is not "true" :)
>
> I missed the recursion, yes, but it could be done another way.
>
>>
>> > On 19 Mar 2018, at 10:18, Petr Fischer  wrote:
>> >
>> > Hello, I have some sort of philosophical question about ifTrue:/ifFalse: 
>> > implementation.
>> >
>> > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in 
>> > True and False classes, so, we can send this message to the boolean 
>> > expressions (instances) only, otherwise DND occurs.
>> >
>> > But we can also define one universal ifTrue: right in the Object class, in 
>> > this style:
>> >
>> > Object>>ifTrue: 
>> > (self = true) ifTrue: [ ... ].
>> >
>> > then, we can send ifTrue: message to ANY object and it will work correctly 
>> > without DND exception on non-boolean objects.
>> >
>> > Is something bad about this idea?
>> >
>> > Thanks! pf
>> >
>>
>>
>

Re: [Pharo-users] inquiring question about ifTrue: implementation

[Damien Pollet]

On 19 March 2018 at 13:40, Petr Fischer  wrote:

> > How would you define the semantics of
> >
> > 123 ifTrue: [ ... ]
>
> 123 is not "true", so, ignore the block.
>

What anout 123 ifFalse: [ … ], then, given that 123 is not false either?

Re: [Pharo-users] inquiring question about ifTrue: implementation

[Petr Fischer]

> Infinite recursion ?
> 
> You use #ifTrue: in your implementation of Object>>#ifTrue:
> 
> Plus, non-booleans cannot meaningfully respond. 
> 
> How would you define the semantics of
> 
> 123 ifTrue: [ ... ]

123 is not "true", so, ignore the block.
Do the ifTrue block only if the receiver is instance of True (true). Everything 
else is not "true" :)

I missed the recursion, yes, but it could be done another way.

> 
> > On 19 Mar 2018, at 10:18, Petr Fischer  wrote:
> > 
> > Hello, I have some sort of philosophical question about ifTrue:/ifFalse: 
> > implementation.
> > 
> > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in 
> > True and False classes, so, we can send this message to the boolean 
> > expressions (instances) only, otherwise DND occurs.
> > 
> > But we can also define one universal ifTrue: right in the Object class, in 
> > this style:
> > 
> > Object>>ifTrue: 
> > (self = true) ifTrue: [ ... ].
> > 
> > then, we can send ifTrue: message to ANY object and it will work correctly 
> > without DND exception on non-boolean objects.
> > 
> > Is something bad about this idea?
> > 
> > Thanks! pf
> > 
> 
> 

Re: [Pharo-users] Disabling GTSpotter dive in

[Ben Coman]

On 19 March 2018 at 16:05, Peter Uhnák  wrote:

> Certainly.
>
> Basically I want to avoid a situation, where diving in would result in an
> empty spotter:
>
>
>
>
>
> So instead I would like to remove the dive in capability (both the icon,
> and the action), when the result will be empty. (And of course keep it if
> there will be something).
>

Rather than removing the icon, please consider modifying the icon to
include a red cross or similar, with a tooltip indicating no results.
I believe that is more explicit than an absent icon.

cheers -ben


>
> Ideally it should be possible to define it in the "parent" step, because
> sometimes I know there will be no further steps, and sometimes the result
> is simply empty (in which case I might still want to show that there are
> zero children).
>
> Thanks,
> Peter
>
> On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba 
> wrote:
>
>> Hi,
>>
>> I am not sure I understand the issue. Can you re-explain it please?
>>
>> Cheers,
>> Doru
>>
>>
>> > On Mar 16, 2018, at 8:02 AM, Peter Uhnák  wrote:
>> >
>> > correction:  spotterForRenderingShapesFor: is not in Pharo 6.1 (it's
>> added by Roassal2GT)
>> >
>> > On Fri, Mar 16, 2018 at 8:01 AM, Peter Uhnák  wrote:
>> > Hi,
>> >
>> > is it possible to disable GTSpotter dive in functionality when the
>> result would be empty?
>> >
>> > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no
>> matter what there will be at least one processor (at least the "parent"
>> one, which is weird).
>> >
>> > Also there are two spotter extensions directly on Object (Pharo 6.1)
>> > * spotterForRenderingShapesFor:
>> > * spotterRePropertiesFor:
>> >
>> > which are always applied... but canDiveIn: was returing true even when
>> I disabled them.
>> >
>> > Thanks,
>> > Peter
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Obvious things are difficult to teach."
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-users] inquiring question about ifTrue: implementation

[Sven Van Caekenberghe]

Infinite recursion ?

You use #ifTrue: in your implementation of Object>>#ifTrue:

Plus, non-booleans cannot meaningfully respond. 

How would you define the semantics of

123 ifTrue: [ ... ]

> On 19 Mar 2018, at 10:18, Petr Fischer  wrote:
> 
> Hello, I have some sort of philosophical question about ifTrue:/ifFalse: 
> implementation.
> 
> Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in 
> True and False classes, so, we can send this message to the boolean 
> expressions (instances) only, otherwise DND occurs.
> 
> But we can also define one universal ifTrue: right in the Object class, in 
> this style:
> 
> Object>>ifTrue: 
>   (self = true) ifTrue: [ ... ].
> 
> then, we can send ifTrue: message to ANY object and it will work correctly 
> without DND exception on non-boolean objects.
> 
> Is something bad about this idea?
> 
> Thanks! pf
> 

[Pharo-users] inquiring question about ifTrue: implementation

[Petr Fischer]

Hello, I have some sort of philosophical question about ifTrue:/ifFalse: 
implementation.

Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in True 
and False classes, so, we can send this message to the boolean expressions 
(instances) only, otherwise DND occurs.

But we can also define one universal ifTrue: right in the Object class, in this 
style:

Object>>ifTrue: 
(self = true) ifTrue: [ ... ].

then, we can send ifTrue: message to ANY object and it will work correctly 
without DND exception on non-boolean objects.

Is something bad about this idea?

Thanks! pf

Re: [Pharo-users] Disabling GTSpotter dive in

[Tudor Girba]

That can be an option.

Doru


> On Mar 19, 2018, at 9:52 AM, Peter Uhnák  wrote:
> 
> So I imagine something like the following
> 
> spotterFieldsFor: aStep
>   
>   ^ aStep listProcessor
>   title: 'Fields';
>   canDiveIn: [ false "or some dynamic condition" ];
>   ...
> 
> On Mon, Mar 19, 2018 at 9:05 AM, Peter Uhnák  wrote:
> Certainly.
> 
> Basically I want to avoid a situation, where diving in would result in an 
> empty spotter:
> 
> 
> 
> 
> 
> 
> So instead I would like to remove the dive in capability (both the icon, and 
> the action), when the result will be empty. (And of course keep it if there 
> will be something).
> 
> Ideally it should be possible to define it in the "parent" step, because 
> sometimes I know there will be no further steps, and sometimes the result is 
> simply empty (in which case I might still want to show that there are zero 
> children).
> 
> Thanks,
> Peter
> 
> On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba  wrote:
> Hi,
> 
> I am not sure I understand the issue. Can you re-explain it please?
> 
> Cheers,
> Doru
> 
> 
> > On Mar 16, 2018, at 8:02 AM, Peter Uhnák  wrote:
> >
> > correction:  spotterForRenderingShapesFor: is not in Pharo 6.1 (it's added 
> > by Roassal2GT)
> >
> > On Fri, Mar 16, 2018 at 8:01 AM, Peter Uhnák  wrote:
> > Hi,
> >
> > is it possible to disable GTSpotter dive in functionality when the result 
> > would be empty?
> >
> > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no matter 
> > what there will be at least one processor (at least the "parent" one, which 
> > is weird).
> >
> > Also there are two spotter extensions directly on Object (Pharo 6.1)
> > * spotterForRenderingShapesFor:
> > * spotterRePropertiesFor:
> >
> > which are always applied... but canDiveIn: was returing true even when I 
> > disabled them.
> >
> > Thanks,
> > Peter
> >
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Obvious things are difficult to teach."
> 
> 
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the 
software gets."

Re: [Pharo-users] Disabling GTSpotter dive in

[Peter Uhnák]

So I imagine something like the following

spotterFieldsFor: aStep

^ aStep listProcessor
title: 'Fields';
*canDiveIn: [ false "or some dynamic condition" ];*
...

On Mon, Mar 19, 2018 at 9:05 AM, Peter Uhnák  wrote:

> Certainly.
>
> Basically I want to avoid a situation, where diving in would result in an
> empty spotter:
>
>
>
>
>
> So instead I would like to remove the dive in capability (both the icon,
> and the action), when the result will be empty. (And of course keep it if
> there will be something).
>
> Ideally it should be possible to define it in the "parent" step, because
> sometimes I know there will be no further steps, and sometimes the result
> is simply empty (in which case I might still want to show that there are
> zero children).
>
> Thanks,
> Peter
>
> On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba 
> wrote:
>
>> Hi,
>>
>> I am not sure I understand the issue. Can you re-explain it please?
>>
>> Cheers,
>> Doru
>>
>>
>> > On Mar 16, 2018, at 8:02 AM, Peter Uhnák  wrote:
>> >
>> > correction:  spotterForRenderingShapesFor: is not in Pharo 6.1 (it's
>> added by Roassal2GT)
>> >
>> > On Fri, Mar 16, 2018 at 8:01 AM, Peter Uhnák  wrote:
>> > Hi,
>> >
>> > is it possible to disable GTSpotter dive in functionality when the
>> result would be empty?
>> >
>> > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no
>> matter what there will be at least one processor (at least the "parent"
>> one, which is weird).
>> >
>> > Also there are two spotter extensions directly on Object (Pharo 6.1)
>> > * spotterForRenderingShapesFor:
>> > * spotterRePropertiesFor:
>> >
>> > which are always applied... but canDiveIn: was returing true even when
>> I disabled them.
>> >
>> > Thanks,
>> > Peter
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Obvious things are difficult to teach."
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-users] Disabling GTSpotter dive in

[Peter Uhnák]

Certainly.

Basically I want to avoid a situation, where diving in would result in an
empty spotter:





So instead I would like to remove the dive in capability (both the icon,
and the action), when the result will be empty. (And of course keep it if
there will be something).

Ideally it should be possible to define it in the "parent" step, because
sometimes I know there will be no further steps, and sometimes the result
is simply empty (in which case I might still want to show that there are
zero children).

Thanks,
Peter

On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba  wrote:

> Hi,
>
> I am not sure I understand the issue. Can you re-explain it please?
>
> Cheers,
> Doru
>
>
> > On Mar 16, 2018, at 8:02 AM, Peter Uhnák  wrote:
> >
> > correction:  spotterForRenderingShapesFor: is not in Pharo 6.1 (it's
> added by Roassal2GT)
> >
> > On Fri, Mar 16, 2018 at 8:01 AM, Peter Uhnák  wrote:
> > Hi,
> >
> > is it possible to disable GTSpotter dive in functionality when the
> result would be empty?
> >
> > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no
> matter what there will be at least one processor (at least the "parent"
> one, which is weird).
> >
> > Also there are two spotter extensions directly on Object (Pharo 6.1)
> > * spotterForRenderingShapesFor:
> > * spotterRePropertiesFor:
> >
> > which are always applied... but canDiveIn: was returing true even when I
> disabled them.
> >
> > Thanks,
> > Peter
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Obvious things are difficult to teach."
>
>
>
>
>
>