Re: [Pharo-dev] Pharo 6 update catalog entries

[Pierce Ng]

On Sat, Feb 04, 2017 at 03:51:43PM -0800, Sean P. DeNigris wrote:
> Ah, interesting! I wonder if this represents a bug then, because
> ChronosManager is in the metarepos for both Pharo 5 and 6, but in Pharo 5
> loads the config from the meta-repo-for-6, not 5...

ConfigOfGlorpSQLite is in both Pharo 5 and 6 meta repos, and 5's catalog
browser currently warns that it is unknown.

I modified CatalogProject class:

createRepositoryURLtoNameMappings
"Return a mapping between repositories URLs and their user names"

^ Dictionary new
"Added the 6.0 line below."
at: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' put: 
'Pharo6.0';
at: self pharoDistributionRepository put: self 
pharoCurrentDottedName;
"at: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main' 
put: 'Pharo5.0';"
at: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main' put: 
'Pharo4.0';
at: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main' put: 
'Pharo3.0';
at: 'http://www.squeaksource.com/MetacelloRepository' put: 
'Unsorted';
yourself

Also created this convenience method in CatalogProject class side:

reset
repositoryURLToNamMappings := nil

After which, sent #reset to CatalogProject, then (don't remember whether any
other steps here in between) clicked refresh in the catalog browser, and now
GlorpSQLite shows up as "Pharo 6.0" in my modified Pharo 5 image.

(And there's somebody on a Hacker News topic about Cuis yesterday freely
sharing their opinion that Pharo is not discoverable...)

Re: [Pharo-dev] I am stuck ProfStef

[Igor Raven via Pharo-dev]

--- Begin Message ---
Disregard my previous message.
Pulled my head out of my butt took a deep breath of fresh air and managed to 
get things input correctly.igor


  From: Igor Raven via Pharo-dev 
 To: "pharo-dev@lists.pharo.org"  
Cc: Igor Raven 
 Sent: Saturday, February 4, 2017 7:25 PM
 Subject: [Pharo-dev] I am stuck ProfStef
   
In ProfStef page 17 or 29 I am stuck"Try to go to the next lesson with a 
cascade of two 'next' messages:"How can I find the solution or
how do I escape to page 19?
Thank you for your helpigor


   --- End Message ---

[Pharo-dev] I am stuck ProfStef

[Igor Raven via Pharo-dev]

--- Begin Message ---
In ProfStef page 17 or 29 I am stuck"Try to go to the next lesson with a 
cascade of two 'next' messages:"How can I find the solution or
how do I escape to page 19?
Thank you for your helpigor
--- End Message ---

Re: [Pharo-dev] Pharo 6 update catalog entries

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> the configs must be copied into MetaRepoForPharo60, this is the way they
> are 'blessed', AFAIU.

Ah, interesting! I wonder if this represents a bug then, because
ChronosManager is in the metarepos for both Pharo 5 and 6, but in Pharo 5
loads the config from the meta-repo-for-6, not 5...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Pharo-6-update-catalog-entries-tp4932354p4933019.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Sven Van Caekenberghe]

> On 4 Feb 2017, at 21:14, stepharong  wrote:
> 
> I will talk about guille about his file implementation and we can see what we 
> can do. 

Yes, that is step 1, here is the issue I was talking about:

https://pharo.fogbugz.com/f/cases/18414/Change-usages-of-StandardFileStream-and-MultiByteFileStream-to-File-decorators

> On Sat, 04 Feb 2017 20:28:07 +0100, Denis Kudriashov  
> wrote:
> 
> 
> 2017-02-04 19:09 GMT+01:00 stepharong :
> Sven
> 
> I really think that we should clean and improve on this side.
> What would be a roadmap?
> 
> - Improve filesystem API to call Zn
> - Deprecated other users? (what are they?)
> - what would be the next steps?
> 
> Yes, we need remove completely old files code.
> Funny that file stream which we use (MultiByteFileStream) is in package 
> 'Files-Deprecated'.
> 
> 
> Funny thing now is deprecated package tag
> 
> 
> 
> -- 
> Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[stepharong]

I will talk about guille about his file implementation and we can see what  
we can do.



On Sat, 04 Feb 2017 20:28:07 +0100, Denis Kudriashov  
 wrote:




2017-02-04 19:09 GMT+01:00 stepharong :

Sven

I really think that we should clean and improve on this side.
What would be a roadmap?

- Improve filesystem API to call Zn
- Deprecated other users? (what are they?)
- what would be the next steps?


Yes, we need remove completely old files code.
Funny that file stream which we use (MultiByteFileStream) is in package  
'Files-Deprecated'.



Funny thing now is deprecated package tag




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[stepharong]

Guilermo's new File class with its simple binary streams can be  
perfectly combined (stacked) with Zn character encoding streams. A first  
step would be to make FileSystem return/produce those stacked streams.


I even believe there is a prototype integrating this

I believe you are one (the ?) author of Nile, so you know very well how  
complex stream users are - that is the challenge. Authors of parsers or  
protocols that depend on streams should write to minimal API's, only  
using what they really need.


Sven my point is that if we want to make progress from this front
we should
slowly improve
once we have in place the new version
then we can plan for migrating
yes it can be tedious and boring but we can do it if we have a plan.

Stef

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Denis Kudriashov]

2017-02-04 19:09 GMT+01:00 stepharong :

> Sven
>
> I really think that we should clean and improve on this side.
> What would be a roadmap?
>
> - Improve filesystem API to call Zn
> - Deprecated other users? (what are they?)
> - what would be the next steps?


Yes, we need remove completely old files code.
Funny that file stream which we use (MultiByteFileStream) is in package
'Files-Deprecated'.


Funny thing now is deprecated package tag

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Sven Van Caekenberghe]

> On 4 Feb 2017, at 19:09, stepharong  wrote:
> 
> 
>>> 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe :
>>> Hi Nicolai,
>>> 
>>> The FileSystem API is a bit inconsistent, yes.
>>> 
>>> This is how you can use it:
>>> 
>>> (FileLocator temp / 'foo.txt') writeStreamDo: [ :out |
>>>  out binary.
>>>  (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ].
>>> 
>>> (FileLocator temp / 'foo.txt') readStreamDo: [ :in |
>>>  in binary.
>>>  ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].
>>> 
>>> (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in |
>>>  (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].
>>> 
>>> There is no #binaryWriteStreamDo:
>>> 
>>> The API around File is more correct, IMHO.
>>> 
>>> Does this help ?
>>> 
>>> Yes, thanks for the fast response.
>>> 
>>> What exactly is your question ?
>>> 
>>> I am looking at the issues with FileList, there are some parts that don't 
>>> work anymore (see FileList>>#contents, it calls some unimplemted methods), 
>>> and it uses TextConverter and somoe parts of the older File api.
>>> It looks like most other (newer) parts are using ZnCharacterReadstream for 
>>> encoding, but I couldn't find a way to use it together with FileReferences 
>>> (most parts of the FileList already operate with the newer FileSystem API.
>> 
>> OK.
>> 
>> From my standpoint and understanding, I would always use binary streams with 
>> explicit Zn converters, this combination is much easier to understand and 
>> better implemented with more features.
>> 
>> If you encounter any problem or have any questions, I will gladly try to 
>> help you.
> 
> Sven
> 
> I really think that we should clean and improve on this side.
> What would be a roadmap?
> 
> - Improve filesystem API to call Zn
> - Deprecated other users? (what are they?)
> - what would be the next steps?
> 
> Stef

Guilermo's new File class with its simple binary streams can be perfectly 
combined (stacked) with Zn character encoding streams. A first step would be to 
make FileSystem return/produce those stacked streams.

I even believe there is a prototype integrating this. 

I believe you are one (the ?) author of Nile, so you know very well how complex 
stream users are - that is the challenge. Authors of parsers or protocols that 
depend on streams should write to minimal API's, only using what they really 
need.

Sven
 

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Thierry Goubier]

Le 04/02/2017 à 19:09, stepharong a écrit :



2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe :
Hi Nicolai,

The FileSystem API is a bit inconsistent, yes.

This is how you can use it:

(FileLocator temp / 'foo.txt') writeStreamDo: [ :out |
  out binary.
  (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ].

(FileLocator temp / 'foo.txt') readStreamDo: [ :in |
  in binary.
  ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].

(FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in |
  (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].

There is no #binaryWriteStreamDo:

The API around File is more correct, IMHO.

Does this help ?

Yes, thanks for the fast response.

What exactly is your question ?

I am looking at the issues with FileList, there are some parts that
don't work anymore (see FileList>>#contents, it calls some
unimplemted methods), and it uses TextConverter and somoe parts of
the older File api.
It looks like most other (newer) parts are using
ZnCharacterReadstream for encoding, but I couldn't find a way to use
it together with FileReferences (most parts of the FileList already
operate with the newer FileSystem API.


OK.

From my standpoint and understanding, I would always use binary
streams with explicit Zn converters, this combination is much easier
to understand and better implemented with more features.

If you encounter any problem or have any questions, I will gladly try
to help you.


Sven

I really think that we should clean and improve on this side.
What would be a roadmap?

- Improve filesystem API to call Zn
- Deprecated other users? (what are they?)
- what would be the next steps?


Have one mode that autoselect another encoding (TZ aware of course) if 
UTF-8 fails... I'm having that one regularly with a mix of utf-8 / 
latin1 files, i.e. C files with french accentuated comments in them.


Thierry


Stef

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[stepharong]

2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe :
Hi Nicolai,

The FileSystem API is a bit inconsistent, yes.

This is how you can use it:

(FileLocator temp / 'foo.txt') writeStreamDo: [ :out |
  out binary.
  (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ].

(FileLocator temp / 'foo.txt') readStreamDo: [ :in |
  in binary.
  ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].

(FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in |
  (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].

There is no #binaryWriteStreamDo:

The API around File is more correct, IMHO.

Does this help ?

Yes, thanks for the fast response.

What exactly is your question ?

I am looking at the issues with FileList, there are some parts that  
don't work anymore (see FileList>>#contents, it calls some unimplemted  
methods), and it uses TextConverter and somoe parts of the older File  
api.
It looks like most other (newer) parts are using ZnCharacterReadstream  
for encoding, but I couldn't find a way to use it together with  
FileReferences (most parts of the FileList already operate with the  
newer FileSystem API.


OK.

From my standpoint and understanding, I would always use binary streams  
with explicit Zn converters, this combination is much easier to  
understand and better implemented with more features.


If you encounter any problem or have any questions, I will gladly try to  
help you.


Sven

I really think that we should clean and improve on this side.
What would be a roadmap?

- Improve filesystem API to call Zn
- Deprecated other users? (what are they?)
- what would be the next steps?

Stef

Re: [Pharo-dev] Pharo 6 update catalog entries

[Sven Van Caekenberghe]

> On 4 Feb 2017, at 16:24, Sean P. DeNigris  wrote:
> 
> kilon.alios wrote
>> Time to make sure they work as expected.
> 
> And tag them #'Pharo6.0' once it's released. In the process of loading
> ChronosManager from the Catalog in Pharo 5, I got a warning that it was not
> marked as safe (sorry I forgot to tell you!). It ended up loading and
> working AFAICT.

Euh, no, the configs must be copied into MetaRepoForPharo60, this is the way 
they are 'blessed', AFAIU.

> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Pharo-6-update-catalog-entries-tp4932354p4932978.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Ben Coman]

> On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman  wrote:
>>
>> Just curious what the magic numbers here relate to...
>> and can they be factored out to a meaningful method name?
>>
>> Context>>gtInspectorVariableValuePairs
>> "This is a helper method that returns a collection of
>> variable_name -> value
>> for the current object.
>> Subclasses can override it to specialize what appears in the variables
>> presentation"
>> | bindings |
>> bindings := OrderedCollection new.
>> 1 to: (self basicSize min: 21) do: [ :index |
>> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt:
>> index)) ].
>> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self
>> haltIf: [ index = 99 ]."
>> bindings add: (index "asString" -> (self basicAt: index)) ].
>> bindings
>> addAll: ((self class allSlots
>> collect: [ :slot | slot name -> (slot read: self) ]) sort
>> asOrderedCollection).
>> ^ bindings
>>
>>
>> cheers -ben
>
>

On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis 
wrote:
> Yes these numbers should be refactored
> For collections only the first and the last 21 elements are displayed in
the
> Raw view. Don't remember why 21.
>
> Cheers,
> Andrei
>

Ahhh. Nice to know.  Here I was thinking it was based on some intrinsic
restriction on the number of variables or something.

I'm a fan of overusing redundant variables for documenting purposes...

Object>>gtInspectorVariableValuePairs
| indexableDisplayLimit bottom topLimit bottomLimit bindings |

indexableDisplayLimit := 21.
top := 1.
bottom := self basicSize.
topLimit := bottom min: indexableDisplayLimit.
bottomLimit := (bottom - indexableDisplayLimit) max: indexableDisplayLimit.

bindings := OrderedCollection new.
"Return top and bottom of indexable elements"
top to: topLimit do: [ :index | bindings add: (index -> (self basicAt:
index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: (index
-> (self basicAt: index)) ].

"Return named variables"
bindings
addAll: ((self class allSlots
collect: [ :slot | slot name -> (slot read: self) ]) sort
asOrderedCollection).
^ bindings

If this looks reasonable I'll do up a slice.

Perhaps defining "top" is overkill - but it does read nice below that.
btw, in general I understand that some smart optimising compilers will
substitute 1 for "top" directly since its assigned a literal and not
reassigned before its use.  I notice from the bytecode this doesn't happen
here.  Is there some intrinsic difficulty in our domain stopping this to
happen, or its just not been a priority.  I guess while stepping through
the debugger "top" a user might set a new value for "top" and reverting the
substitution of "1" for "top" needs the sort of facility that Sista will
provide??


On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba  wrote:

> There is very little meaning behind the number.
>
> The previous inspector showed the first 100 and the last 10 elements. 100
> is anyway too large for a quick inspection, so we picked another number. I
> wanted 42 but that was still large, so we are now at 21.


Well 21 top and bottom gives you 42, and I know life, the universe and
everything depends on that number - so this seems reasonable.


On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel 
 wrote:

> They could be extracted to class vars for example TWENTY_ONE := 21. Later
> if performance is still not good enough they may be changed for example to
> TWENTY_ONE := 15.
> (joke)
>

You mean something like this...
https://xkcd.com/221/


cheers -ben

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Sean P. DeNigris]

Aliaksei Syrel wrote
> Later if performance is still not good enough they may be changed for
> example to
> TWENTY_ONE := 15.

Ha ha ha!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/magic-numbers-in-gtInspectorVariableValuePairs-tp4932831p4932979.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Pharo 6 update catalog entries

[Sean P. DeNigris]

kilon.alios wrote
> Time to make sure they work as expected.

And tag them #'Pharo6.0' once it's released. In the process of loading
ChronosManager from the Catalog in Pharo 5, I got a warning that it was not
marked as safe (sorry I forgot to tell you!). It ended up loading and
working AFAICT.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Pharo-6-update-catalog-entries-tp4932354p4932978.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] GTDebugger variables table

[stepharong]

On Thu, 02 Feb 2017 17:16:49 +0100, John Brant  
 wrote:



On 02/02/2017 04:22 AM, Denis Kudriashov wrote:


Now I think I realized main reason of my confusion. Temps and receiver
vars are not just in single table but they are also sorted by name all
together.


I'm not a fan of this either. While I can filter by the type of variable  
to limit the list, the next time I step the debugger, the whole list  
resets. The list filter and selection should be kept across steps in the  
debugger (if possible).


Some might argue that you should have fewer variables so the list would  
be easier to use in the debugger. However, if you are using the  
debugger, likely you are still in the "make it work" phase and haven't  
performed the factoring from the "make it right" phase.


+ 1 and under stress


I think my preference would be to have several tabs for the variables.  
In addition to the one tab that we have now that shows all variables, I  
can think of tabs for locals, inst vars, interesting variables, watched  
variables/expressions, and stack variables. Locals would show just the  
method/block arguments and any temps defined in the method. Inst vars  
would show the object's inst vars (and maybe class vars, however these  
would only appear after the inst vars).


Interesting variables would show locals and inst vars used by the  
method. The locals would be limited to the ones that are still active at  
the current location in the method. For example, if you are in a block,  
it would only show variables used in the block. Also, if you are  
before(/after) the first(/final) use of the variable, it wouldn't show  
in the interesting list. Interesting variables should also do some  
analysis to see what accessor methods are used and show their  
corresponding variables.


I like that



Watched variables/expressions would be user controlled. The user could  
add/remove variables or expressions. These variables/expressions would  
remain across different methods. If a variable didn't exist in the other  
method, "Invalid" could be displayed.


Finally, stack variables would display the whole stack and not just the  
top item. I like the ability to see the stack top, but it really doesn't  
work if you want to see the first argument of a two argument message  
send. For example, if you debug "Array with: OrderedCollection new with:  
Set new", stepping over the "OrderedCollection new" immediately pushes  
the "Set" class on the stack so you can't see the "OrderedCollection  
new" object.


I like that now when we have too many tabs it often happens that
only two are useful.



BTW, the current variable list sometimes shows 'error obtaining field  
value' for temporaries when stepping through a method. I'm not sure why  
it occurs, but it should always be able to display the temp variables.



John Brant




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Sven Van Caekenberghe]

> On 4 Feb 2017, at 13:01, Nicolai Hess  wrote:
> 
> 
> 
> 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe :
> Hi Nicolai,
> 
> The FileSystem API is a bit inconsistent, yes.
> 
> This is how you can use it:
> 
> (FileLocator temp / 'foo.txt') writeStreamDo: [ :out |
>   out binary.
>   (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ].
> 
> (FileLocator temp / 'foo.txt') readStreamDo: [ :in |
>   in binary.
>   ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].
> 
> (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in |
>   (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].
> 
> There is no #binaryWriteStreamDo:
> 
> The API around File is more correct, IMHO.
> 
> Does this help ?
> 
> Yes, thanks for the fast response.
>  
> What exactly is your question ?
> 
> I am looking at the issues with FileList, there are some parts that don't 
> work anymore (see FileList>>#contents, it calls some unimplemted methods), 
> and it uses TextConverter and somoe parts of the older File api.
> It looks like most other (newer) parts are using ZnCharacterReadstream for 
> encoding, but I couldn't find a way to use it together with FileReferences 
> (most parts of the FileList already operate with the newer FileSystem API.

OK. 

From my standpoint and understanding, I would always use binary streams with 
explicit Zn converters, this combination is much easier to understand and 
better implemented with more features.

If you encounter any problem or have any questions, I will gladly try to help 
you.

> Sven
> 
> > On 4 Feb 2017, at 12:09, Nicolai Hess  wrote:
> >
> > Hi
> > How can I specify the character encoding when opening a readStream on a 
> > FileRerefence.
> >
> > I found this, that works:
> >
> > | readStream fileContent |
> > readStream := (File named: aFileName) openForRead.
> > fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
> >  fileContent upToEnd asString.
> >
> > But if I try to do the same with a readStream from a FileReference
> >
> > | readStream fileContent |
> > readStream := aFileName asFileReference readStream.
> > fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
> >  fileContent upToEnd asString.
> >
> > I get an error SmallInteger DNU #asciiValue,
> >
> > this is because, in the first method, we create a binary filestream, and if 
> > we
> > use readStream from a FileReference, the stream is a MultibyteFileStream.
> >
> > How can I us ZnEncoder for a readstream from a FileReference?
> >
> > (and is it on purpose that both readStream method (openForRead/readStream)
> > return different kinds of binary streams?)
> >
> >
> > nicolai

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Sven Van Caekenberghe]

Hi Nicolai,

The FileSystem API is a bit inconsistent, yes. 

This is how you can use it:

(FileLocator temp / 'foo.txt') writeStreamDo: [ :out |
  out binary.
  (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ].

(FileLocator temp / 'foo.txt') readStreamDo: [ :in |
  in binary.
  ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].

(FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in |
  (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].

There is no #binaryWriteStreamDo:

The API around File is more correct, IMHO.

Does this help ?
What exactly is your question ?

Sven

> On 4 Feb 2017, at 12:09, Nicolai Hess  wrote:
> 
> Hi 
> How can I specify the character encoding when opening a readStream on a 
> FileRerefence.
> 
> I found this, that works:
> 
> | readStream fileContent |
> readStream := (File named: aFileName) openForRead.
> fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
>  fileContent upToEnd asString.
> 
> But if I try to do the same with a readStream from a FileReference
> 
> | readStream fileContent |
> readStream := aFileName asFileReference readStream.
> fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
>  fileContent upToEnd asString.
> 
> I get an error SmallInteger DNU #asciiValue,
> 
> this is because, in the first method, we create a binary filestream, and if we
> use readStream from a FileReference, the stream is a MultibyteFileStream.
> 
> How can I us ZnEncoder for a readstream from a FileReference?
> 
> (and is it on purpose that both readStream method (openForRead/readStream) 
> return different kinds of binary streams?)
> 
> 
> nicolai

Re: [Pharo-dev] [pharo-project/pharo-core] 16537e: 60373

[denker]

> 
>  Log Message:
>  ---
>  60373
> Moose


This is:

This version addresses some bug fixes and synchronises those packages 
integrated using slices with the GToolkit repos. Changes:

- case 19575
- case 19646
- case 19604
- case 19542
- case 19260
- case 19454
- FastTable/List/Tree presentations can set rowHeight.
- Set to the Source presentation of a Context object doItReceiver and 
doItContext.

Marcus

[Pharo-dev] [pharo-project/pharo-core] 16537e: 60373

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 16537e5cd5348d1f146143b6ed8077b63cb9cb63
  
https://github.com/pharo-project/pharo-core/commit/16537e5cd5348d1f146143b6ed8077b63cb9cb63
  Author: Jenkins Build Server 
  Date:   2017-02-04 (Sat, 04 Feb 2017)

  Changed paths:
M 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version37_.st
M 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version14_.st
M 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version325_.st
M 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version321_.st
M 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version223_.st
M 
ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version333_.st
M 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version432_.st
M 
GT-InspectorExtensions-Core.package/extension/Context/instance/gtInspectorSourceIn_.st
M 
GT-InspectorExtensions-Core.package/extension/KMCategory/instance/gtDisplayOn_.st
A 
GT-Playground.package/extension/GlamourPresentationModel/class/examplePlaygroundAndInspectorOn42.st
A 
GT-Playground.package/extension/GlamourPresentationModel/class/examplePlaygroundOn42.st
A 
GT-Playground.package/extension/GlamourPresentationModel/class/playgroundOn_.st
R GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/README.md
R GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/definition.st
R 
GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/instance/public/doSomething.st
R 
GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/instance/public/doSomethingElse.st
R 
GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/instance/public/something1.st
R 
GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/instance/public/something2.st
R 
GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/instance/public/something3.st
R 
GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/instance/public/something4.st
R 
GT-Tests-Spotter.package/GTImplementorsSpotterMock1.class/instance/public/something5.st
M 
Glamour-Core.package/GLMCompositePresentation.class/instance/scripting/custom_.st
M 
Glamour-FastTable.package/GLMFastTreeDataSource.class/instance/private/rowMorphForItem_.st
M 
Glamour-FastTable.package/GLMMorphicFTRenderer.class/instance/initialization/specificTableMorphInitializiation.st
A 
Glamour-FastTable.package/GLMMorphicFTTest.class/instance/tests/testTypeOfMultipleSelection.st
M 
Glamour-FastTable.package/TGLMFastTable.class/instance/selecting/selection_.st
A 
Glamour-FastTable.package/TGLMFastTableFunctionsPresentation.class/class/accessing/defaultRowHeight.st
A 
Glamour-FastTable.package/TGLMFastTableFunctionsPresentation.class/instance/public
 api/rowHeight.st
A 
Glamour-FastTable.package/TGLMFastTableFunctionsPresentation.class/instance/public
 api/rowHeightBlock.st
A 
Glamour-FastTable.package/TGLMFastTableFunctionsPresentation.class/instance/public
 api/rowHeight_.st
A 
Glamour-FastTable.package/extension/GLMBasicExamples/instance/fastListDoubleHeight.st
A 
Glamour-FastTable.package/extension/GLMBasicExamples/instance/fastListDoubleHeightCustomFormat.st
A 
Glamour-FastTable.package/extension/GLMBasicExamples/instance/fastListDoubleHeightCustomFormatAndTags.st
A 
Glamour-FastTable.package/extension/GLMBasicExamples/instance/fastListMultipleSelection.st
A 
Glamour-Morphic-Renderer.package/GLMMorphicWindowRenderer.class/instance/rendering/actOnPresentationToolbarUpdated_.st
M 
Glamour-Morphic-Renderer.package/GLMMorphicWindowRenderer.class/instance/rendering/render_.st
M 
Glamour-Morphic-Widgets.package/GLMSystemWindow.class/instance/accessing/toolbarBox_.st
M 
Glamour-Rubric-Presentations.package/GLMHighlighterTextRubEditingMode.class/README.md

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

[Nicolai Hess]

Hi
How can I specify the character encoding when opening a readStream on a
FileRerefence.

I found this, that works:

| readStream fileContent |
readStream := (File named: aFileName) openForRead.
fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
 fileContent upToEnd asString.

But if I try to do the same with a readStream from a FileReference

| readStream fileContent |
readStream := aFileName asFileReference readStream.
fileContent := ZnCharacterReadStream on: readStream encoding: encoding.
 fileContent upToEnd asString.

I get an error SmallInteger DNU #asciiValue,

this is because, in the first method, we create a binary filestream, and if
we
use readStream from a FileReference, the stream is a MultibyteFileStream.

How can I us ZnEncoder for a readstream from a FileReference?

(and is it on purpose that both readStream method (openForRead/readStream)
return different kinds of binary streams?)


nicolai