Re: [Pharo-users] Unable to update Glamour-Core

[Tudor Girba]

Hi,

I am not sure I understand your report. The Glamour-Core package is part of 
ConfigurationOfGlamourCore, and should not be updated separately.

What script are you using for loading ConfigurationOfGlamourCore?

Cheers,
Doru


> On Nov 29, 2017, at 3:53 AM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> My image become unresponsive while making some debug, so I decided to
> start fresh and reinstall Grafoscopio, but I have some problems, with
> XML parser (so I disabled Soup temporarily) and with Glamour-Core, which
> provides and important part of the Grafoscopio experience. I tried also
> to install it from Monticello, without better results (to the version
> Glamour-Core-TudorGirba339). In both cases I get "SubscriptOutOfBounds:
> 17808" and this is the trace I get with the "Report" button (sorry I
> don't know other way to report):
> 
> https://pastebin.com/wWM24w01
> 
> I will try with Pharo 7... The procedure is the same that was working
> just last week. I know the pains and advantages of having a dynamic
> system that is evolving quickly... hopefully a more stable platform will
> be there while the upcoming one is evolving.
> 
> Cheers,
> 
> Offray
> 
> 
> 

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

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."

Re: [Pharo-users] files.pharo.org downloads => needs testers

[john pfersich]

Stats from Las Vegas, Nevada, USA on Mac OS

curl -o 1.zip
http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
\

> --next -o 2.zip
http://file-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
\

> --next -o 3.zip
http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip

  % Total% Received % Xferd  Average Speed   TimeTime Time
Current

 Dload  Upload   Total   SpentLeft
Speed

100 17.7M  100 17.7M0 0  3306k  0  0:00:05  0:00:05 --:--:--
4465k

  % Total% Received % Xferd  Average Speed   TimeTime Time
Current

 Dload  Upload   Total   SpentLeft
Speed

100 17.7M  100 17.7M0 0  1411k  0  0:00:12  0:00:12 --:--:--
2688k

  % Total% Received % Xferd  Average Speed   TimeTime Time
Current

 Dload  Upload   Total   SpentLeft
Speed

100 17.7M  100 17.7M0 0  1429k  0  0:00:12  0:00:12 --:--:--
2510k


On Tue, Nov 28, 2017 at 9:38 PM, john pfersich  wrote:

> Stats from Las Vegas, Nevada, USA
>
> curl -o 1.zip http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.
> 328.sha.c366633.arch.32bit.zip --next -o 2.zip http://file-pharo.inria.fr/
> image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip --next -o
> 3.zip http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.
> 328.sha.c366633.arch.32bit.zip
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> 100 17.7M  100 17.7M0 0   270k  0  0:01:07  0:01:07 --:--:--
> 462k
> 100 17.7M  100 17.7M0 0   282k  0  0:01:04  0:01:04 --:--:--
> 312k
> 100 17.7M  100 17.7M0 0   294k  0  0:01:01  0:01:01 --:--:--
> 336k
>
>
> On Tue, Nov 28, 2017 at 7:31 PM, Ben Coman  wrote:
>
>> and the XLS file in case anyone wants to provide other observations in a
>> similar format...
>>
>>
>> On 29 November 2017 at 11:29, Ben Coman  wrote:
>>
>>>
>>>
>>> On 29 November 2017 at 00:43, Christophe Demarey <
>>> christophe.dema...@inria.fr> wrote:
>>> > Hi all,
>>> >
>>> > We set up 2 new servers to replace (at least for some time) the
>>> problematic
>>> > files.pharo.org server (slow downloads, bad CRC).
>>> > Please, could you test these new servers and give us feedback to see if
>>> > downloads are fast and nom ore CRC errors?
>>> > * http://file-pharo.inria.fr/
>>> > * http://files2.pharo.org (hosted on the cloud)
>>> >
>>> > Data might be a bit outdated (sync last friday) but is just for
>>> testing now.
>>> >
>>> > According to your feedbacks, we will switch official URLs to one of
>>> these
>>> > servers.
>>>
>>> Performance from Western Australia...
>>>
>>> $ curl -o 1.zip http://files2.pharo.org/image/
>>> 70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip \
>>> --next -o 2.zip http://file-pharo.inria.fr/ima
>>> ge/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip \
>>> --next -o 3.zip http://files.pharo.org/image/7
>>> 0/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
>>>
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>>  Current
>>>  Dload  Upload   Total   SpentLeft
>>>  Speed
>>> 100 17.7M  100 17.7M0 0   228k  0  0:01:19  0:01:19 --:--:--
>>>  271k
>>> 100 17.7M  100 17.7M0 0   124k  0  0:02:25  0:02:25 --:--:--
>>>  134k
>>> 100 17.7M  100 17.7M0 0   142k  0  0:02:07  0:02:07 --:--:--
>>>  190k
>>>
>>>
>>> Attached chart built from and screen grabs of `uget-gtk` on Ubuntu
>>> 16.04/64bit
>>> 1.zip... files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.327.sha.33
>>> fc2a4.arch.32bit.zip
>>> 2.zip... fiile-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.344.sh
>>> a.233512f.arch.32bit.zip
>>> 3.zip... files.pharo.org/image/70/Pharo-7.0.0-alpha.build.344.sha.233
>>> 512f.arch.32bit.zip
>>>
>>> And btw, I'd call this a good day for files.pharo.org.
>>>
>>> cheers -ben
>>>
>>
>>
>

Re: [Pharo-users] files.pharo.org downloads => needs testers

[john pfersich]

Stats from Las Vegas, Nevada, USA

curl -o 1.zip
http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
--next -o 2.zip
http://file-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
--next -o 3.zip
http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
  % Total% Received % Xferd  Average Speed   TimeTime Time
Current
 Dload  Upload   Total   SpentLeft
Speed
100 17.7M  100 17.7M0 0   270k  0  0:01:07  0:01:07 --:--:--
462k
100 17.7M  100 17.7M0 0   282k  0  0:01:04  0:01:04 --:--:--
312k
100 17.7M  100 17.7M0 0   294k  0  0:01:01  0:01:01 --:--:--
336k


On Tue, Nov 28, 2017 at 7:31 PM, Ben Coman  wrote:

> and the XLS file in case anyone wants to provide other observations in a
> similar format...
>
>
> On 29 November 2017 at 11:29, Ben Coman  wrote:
>
>>
>>
>> On 29 November 2017 at 00:43, Christophe Demarey <
>> christophe.dema...@inria.fr> wrote:
>> > Hi all,
>> >
>> > We set up 2 new servers to replace (at least for some time) the
>> problematic
>> > files.pharo.org server (slow downloads, bad CRC).
>> > Please, could you test these new servers and give us feedback to see if
>> > downloads are fast and nom ore CRC errors?
>> > * http://file-pharo.inria.fr/
>> > * http://files2.pharo.org (hosted on the cloud)
>> >
>> > Data might be a bit outdated (sync last friday) but is just for testing
>> now.
>> >
>> > According to your feedbacks, we will switch official URLs to one of
>> these
>> > servers.
>>
>> Performance from Western Australia...
>>
>> $ curl -o 1.zip http://files2.pharo.org/image/
>> 70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip \
>> --next -o 2.zip http://file-pharo.inria.fr/ima
>> ge/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip \
>> --next -o 3.zip http://files.pharo.org/image/7
>> 0/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
>>
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>  Current
>>  Dload  Upload   Total   SpentLeft
>>  Speed
>> 100 17.7M  100 17.7M0 0   228k  0  0:01:19  0:01:19 --:--:--
>>  271k
>> 100 17.7M  100 17.7M0 0   124k  0  0:02:25  0:02:25 --:--:--
>>  134k
>> 100 17.7M  100 17.7M0 0   142k  0  0:02:07  0:02:07 --:--:--
>>  190k
>>
>>
>> Attached chart built from and screen grabs of `uget-gtk` on Ubuntu
>> 16.04/64bit
>> 1.zip... files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.327.sha.
>> 33fc2a4.arch.32bit.zip
>> 2.zip... fiile-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.344.sh
>> a.233512f.arch.32bit.zip
>> 3.zip... files.pharo.org/image/70/Pharo-7.0.0-alpha.build.344.sha.
>> 233512f.arch.32bit.zip
>>
>> And btw, I'd call this a good day for files.pharo.org.
>>
>> cheers -ben
>>
>
>

Re: [Pharo-users] UFFI C basic types passed-by-reference for output

[Ben Coman]

On 15 November 2017 at 20:47, Esteban Lorenzano  wrote:
>
> which could be implemented...
>FFIExternalType class >> newBuffer.
> ^ByteArray new: (self externalTypeSize)
>
> testGetPageSizeByIndex
> | document page_index widthBuffer heightBuffer width height result|
> PDFium FPDF_InitLibrary.
> document := PDFium FPDF_LoadDocument__file_path:  helloPdf
> password: ''.
> widthBuffer := FFIFloat64 buffer.
> heightBuffer := FFIFloat64 buffer.
> page_index := 0. "Its zero based"
> result := PDFium FPDF_GetPageSizeByIndex__document: document
>  page_index: 0
>  width: widthBuffer
>  height: heightBuffer.
> width := widthBuffer doubleAt: 1.
> height := heightBuffer doubleAt: 1.

I'm about to do something similar with for this prototype...
void clang_getFileLocation(
 CXSourceLocation location,
 CXFile *file,
 unsigned *line,
 unsigned *column,
 unsigned *offset);

Now 'uints' are good to work with since they are consistently 4 bytes
on all modern platforms
(Windows / Linux / Unix) x (32bit / 64bit)
http://nickdesaulniers.github.io/blog/2016/05/30/data-models-and-word-size/

So I using this FFI definition...
Libclang >> clang_getFileLocation__location: location file: file
line: line column: column offset: offset
self ffiCall: #(void clang_getFileLocation(
CXSourceLocation location,
CXFile *file,
uint *line,
uint *column,
uint *offset))

with this application code...
lineBuffer := FFIUInt32 newBuffer.
columnBuffer := FFIUInt32 newBuffer.
offsetBuffer := FFIUInt32 newBuffer.
Libclang clang_getFileLocation__location: cxLocation
file: cxFile
line: lineBuffer
column: columnBuffer
offset: offsetBuffer.

but to unwrap the buffer the following is not available...
 line := lineBuffer uint32At: 1.

Other candidates are senders of #integerAt:size:signed:
from which the only one dealing in 4 bytes is...
ByteArray >> unsignedLongAt: byteOffset
  ^self integerAt: byteOffset size: 4 signed: false

which (apart from 'ulong' being semantically different from the
original 'uint' C definition)
seems a poor cross-platform choice, since 'long' is the only integer
type whose size that varies between 32-bit & 64-bit.
* 
https://software.intel.com/en-us/articles/size-of-long-integer-type-on-different-architecture-and-os

There is ByteArray >> platformUnsignedLongAt:
but again the original C declaration was an uint, so it still feels
wrong to use 'long' converter.

The remaining option is directly using the lower level api, but its a
bit ugly...
lineBuffer := FFIUInt32 newBuffer.
columnBuffer := FFIUInt32 newBuffer.
offsetBuffer := FFIUInt32 newBuffer.
Libclang clang_getFileLocation__location: cxLocation
file: cxFile
line: lineBuffer
column: columnBuffer
offset: offsetBuffer.
line := lineBuffer integerAt: 1 size: 4 signed: false.
column := columnBuffer integerAt: 1 size: 4 signed: false.
offset := offsetBuffer integerAt: 1 size: 4 signed: false.
^{ line . column. offset }

So are additional type converters required for ByteArray?

Or alternatively, could FFIExternalType get an extra ByteArray instance variable
that is usually nil, but is available when we want to deal concretely
with an external type
while keeping the type info associated, rather needing a raw ByteArray.
For example...

Object subclass: #FFIExternalType
instanceVariableNames: 'pointerArity loader buffer'
classVariableNames: ''
package: 'UnifiedFFI-Types'

FFIExternalType >> buffer
 ^ buffer ifNil: [ buffer := ByteArray new: (self externalTypeSize) ].
buffer pin.

FFIExternalType >> dereference
^ self basicHandle: self buffer at: 1

then presumably I could do "something" like...

line := FFIUInt32 new.
column := FFIUInt32 new.
offset := FFIUInt32 new.
Libclang clang_getFileLocation__location: cxLocation
file: cxFile
line: line buffer
column: column buffer
offset: offset buffer.
^ { line value . column value . offset value}

or maybe #bufferPointer would be better than #buffer

I'm experimenting along this line, but I'm currently breaking my Image
so I pause to seek feedback on the idea.

cheers -ben

Re: [Pharo-users] files.pharo.org downloads => needs testers

[Ben Coman]

and the XLS file in case anyone wants to provide other observations in a
similar format...


On 29 November 2017 at 11:29, Ben Coman  wrote:

>
>
> On 29 November 2017 at 00:43, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
> > Hi all,
> >
> > We set up 2 new servers to replace (at least for some time) the
> problematic
> > files.pharo.org server (slow downloads, bad CRC).
> > Please, could you test these new servers and give us feedback to see if
> > downloads are fast and nom ore CRC errors?
> > * http://file-pharo.inria.fr/
> > * http://files2.pharo.org (hosted on the cloud)
> >
> > Data might be a bit outdated (sync last friday) but is just for testing
> now.
> >
> > According to your feedbacks, we will switch official URLs to one of these
> > servers.
>
> Performance from Western Australia...
>
> $ curl -o 1.zip http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.
> 328.sha.c366633.arch.32bit.zip \
> --next -o 2.zip http://file-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.
> build.328.sha.c366633.arch.32bit.zip \
> --next -o 3.zip http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.
> 328.sha.c366633.arch.32bit.zip
>
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100 17.7M  100 17.7M0 0   228k  0  0:01:19  0:01:19 --:--:--
>  271k
> 100 17.7M  100 17.7M0 0   124k  0  0:02:25  0:02:25 --:--:--
>  134k
> 100 17.7M  100 17.7M0 0   142k  0  0:02:07  0:02:07 --:--:--
>  190k
>
>
> Attached chart built from and screen grabs of `uget-gtk` on Ubuntu
> 16.04/64bit
> 1.zip... files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.327.
> sha.33fc2a4.arch.32bit.zip
> 2.zip... fiile-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.344.
> sha.233512f.arch.32bit.zip
> 3.zip... files.pharo.org/image/70/Pharo-7.0.0-alpha.build.344.
> sha.233512f.arch.32bit.zip
>
> And btw, I'd call this a good day for files.pharo.org.
>
> cheers -ben
>


FileServerPerformance.xlsx
Description: MS-Excel 2007 spreadsheet

Re: [Pharo-users] Unable to update Glamour-Core

[Offray Vladimir Luna Cárdenas]

I have no luck either with Pharo 7. After enabling my ssh GitHub keys I
get all the time this error message:

'IceDuplicatedRepository: You already have an Iceberg repository
at
/home/offray/Programas/Pharo/7/pharo-local/iceberg/feenkcom/gtoolkit-examples

and with the same origin URL.

If you really whant create another one,
please locate it in a different directory.'

and installation stops.

At least this time updating errors are happening two days before the
actual workshop but is not the best ambassador experience for Pharo and
the people learning about it when the same install from previous week
just stops working this one.

:-/

What we need to create reliable installation procedures for Pharo
packages and its dependencies?

Cheers,

Offray


On 28/11/17 21:53, Offray Vladimir Luna Cárdenas wrote:
> Hi,
>
> My image become unresponsive while making some debug, so I decided to
> start fresh and reinstall Grafoscopio, but I have some problems, with
> XML parser (so I disabled Soup temporarily) and with Glamour-Core, which
> provides and important part of the Grafoscopio experience. I tried also
> to install it from Monticello, without better results (to the version
> Glamour-Core-TudorGirba339). In both cases I get "SubscriptOutOfBounds:
> 17808" and this is the trace I get with the "Report" button (sorry I
> don't know other way to report):
>
> https://pastebin.com/wWM24w01
>
> I will try with Pharo 7... The procedure is the same that was working
> just last week. I know the pains and advantages of having a dynamic
> system that is evolving quickly... hopefully a more stable platform will
> be there while the upcoming one is evolving.
>
> Cheers,
>
> Offray
>
>
>
>

Re: [Pharo-users] files.pharo.org downloads => needs testers

[Ben Coman]

On 29 November 2017 at 00:43, Christophe Demarey <
christophe.dema...@inria.fr> wrote:
> Hi all,
>
> We set up 2 new servers to replace (at least for some time) the
problematic
> files.pharo.org server (slow downloads, bad CRC).
> Please, could you test these new servers and give us feedback to see if
> downloads are fast and nom ore CRC errors?
> * http://file-pharo.inria.fr/
> * http://files2.pharo.org (hosted on the cloud)
>
> Data might be a bit outdated (sync last friday) but is just for testing
now.
>
> According to your feedbacks, we will switch official URLs to one of these
> servers.

Performance from Western Australia...

$ curl -o 1.zip
http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
\
--next -o 2.zip
http://file-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip
\
--next -o 3.zip
http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip

  % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
 Dload  Upload   Total   SpentLeft
 Speed
100 17.7M  100 17.7M0 0   228k  0  0:01:19  0:01:19 --:--:--
 271k
100 17.7M  100 17.7M0 0   124k  0  0:02:25  0:02:25 --:--:--
 134k
100 17.7M  100 17.7M0 0   142k  0  0:02:07  0:02:07 --:--:--
 190k


Attached chart built from and screen grabs of `uget-gtk` on Ubuntu
16.04/64bit
1.zip...
files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.327.sha.33fc2a4.arch.32bit.zip
2.zip...
fiile-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.344.sha.233512f.arch.32bit.zip
3.zip...
files.pharo.org/image/70/Pharo-7.0.0-alpha.build.344.sha.233512f.arch.32bit.zip

And btw, I'd call this a good day for files.pharo.org.

cheers -ben

[Pharo-users] Unable to update Glamour-Core

[Offray Vladimir Luna Cárdenas]

Hi,

My image become unresponsive while making some debug, so I decided to
start fresh and reinstall Grafoscopio, but I have some problems, with
XML parser (so I disabled Soup temporarily) and with Glamour-Core, which
provides and important part of the Grafoscopio experience. I tried also
to install it from Monticello, without better results (to the version
Glamour-Core-TudorGirba339). In both cases I get "SubscriptOutOfBounds:
17808" and this is the trace I get with the "Report" button (sorry I
don't know other way to report):

https://pastebin.com/wWM24w01

I will try with Pharo 7... The procedure is the same that was working
just last week. I know the pains and advantages of having a dynamic
system that is evolving quickly... hopefully a more stable platform will
be there while the upcoming one is evolving.

Cheers,

Offray

Re: [Pharo-users] I love the launcher!!!!

[Stephane Ducasse]

Christophe

I think that we should remove the blessed folder.

Setf

On Tue, Nov 28, 2017 at 5:36 PM, Christophe Demarey
 wrote:
> Hi Phil,
>
> Le 26 nov. 2017 à 22:25, p...@highoctane.be a écrit :
>
> So, I try it on my CentOS 7 64 bit and... as there is no 64 bit version of
> the launcher…
>
>
> Right.
> Can’t you use the 32 bit version?
> Anyway, I think it would be good to have a 64 bit version.  Could you open
> an issue for that please?
>
>
> pharo6-64-ui PharoLauncher.image
> This interpreter (vers. 68021) cannot read image file (vers. 6521).
> Press CR to quit...
>
> How is one using the launcher for 64 bit stuff?
>
> Phil
>
> On Sun, Nov 26, 2017 at 9:45 PM, Stephane Ducasse 
> wrote:
>>
>> If you don't try you will not understand what you miss.
>>
>> On Sun, Nov 26, 2017 at 2:10 PM, Herby Vojčík  wrote:
>> > Stephane Ducasse wrote:
>> >>
>> >> Then do not try :) like that you will never get a chance to know :)
>> >
>> >
>> > Could you please explain? I understood your sentence has high dose of
>> > homour
>> > which I cannot decipher since I lack certain abilities for that.
>> >
>> > Thanks, Herby
>> >
>> >> Stef
>> >>
>> >>
>> >> On Sun, Nov 26, 2017 at 1:48 PM, Herby Vojčík  wrote:
>> >>>
>> >>> Stephane Ducasse wrote:
>> 
>>  Why don't you try? It does not bite.
>> 
>>  For me it works in all scenario. I have projects that i manage over
>>  several weeks and others I drop day to day.
>>  And I have also startup script per versions.
>> >>>
>> >>>
>> >>> Maybe I will. The main problem was I didn't what it's good about at
>> >>> all -
>> >>> load image for a version, runs it - what's the "wow it's great" about?
>> >>> Missed part was it loads correct vm; plus makes sense when you have
>> >>> hundreds
>> >>> (I don't). Now it must be combined with the startup script magic to
>> >>> work
>> >>> with long-time projects, but those are also new to me - did not know
>> >>> of
>> >>> them
>> >>> until your booklet, not using them at all yet.
>> >>>
>> >>> Herby
>> >>>
>> >>>
>>  Stef
>> 
>>  On Fri, Nov 24, 2017 at 3:10 PM, Herby Vojčík
>>  wrote:
>> >
>> > Thank you all, now I understand it better. Good for lots of
>> > "branches".
>> >
>> > However, I wonder how does it work with the rule I read somewhere:
>> > "start
>> > each day [of work on a project] with a new image", which means I
>> > should
>> > not
>> > reuse clean new image (as it needs populating from VCSes etc.) nor
>> > reuse
>> > existing image (I should start with the new one). Or does it combine
>> > with
>> > some startup-magic described in one of the recent Steph's booklets,
>> > the
>> > "one
>> > start per [new] image" case (but again, one should discriminate
>> > projects
>> > from each other)?
>> >
>> > Thanks, Herby
>> >
>> > Peter Uhnák wrote:
>> >>
>> >> Hi Herby,
>> >>
>> >> normally people use different images for their different projects,
>> >> different versions, trying things, etc. Which means we end up with
>> >> many
>> >> locations on disk, and it can be hard to track.
>> >> So PharoLauncher is a nice tool where you can download fresh image
>> >> just
>> >> by clicking, and you see the list of your local images and can
>> >> launch
>> >> them, etc.
>> >>
>> >> Peter
>> >>
>> >> On Thu, Nov 23, 2017 at 12:56 PM, Herby Vojčík> >> >   wrote:
>> >>
>> >>   Stephane Ducasse wrote:
>> >>
>> >>   Hi
>> >>
>> >>   I love the PharoLauncher.
>> >>
>> >>
>> >>   Pardon my question, I have downloaded it and looked at it,
>> >> but I
>> >>   don't get it. What does it do / what are the use cases
>> >> (honest
>> >>   question)?
>> >>
>> >>   Thanks, Herby
>> >>
>> >>
>> >>   It helps me to manage my parallel development and
>> >> projects.
>> >>
>> >>   We should put a link on the Pharo web site because
>> >>
>> >>   http://files.pharo.org/platform/launcher/
>> >>   
>> >>
>> >>   is arcane.
>> >>
>> >>   Stef
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>
>> >
>> >
>>
>>
>
>

Re: [Pharo-users] PetitCompiler loading problem

[Julien]

Hello,

Sorry for the late answer. I use the following script:

Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser';
configurationOf: #PetitCompiler; load.
(Smalltalk at: #ConfigurationOfPetitCompiler) perform: #'loadDevelopment’.

Julien

---
Julien Delplanque
http://juliendelplanque.be/phd.html
Doctorant à l’Université de Lille 1
Equipe Rmod, Inria
Numéro de téléphone: +333 59 35 86 40

> Le 24 nov. 2017 à 09:57, Tudor Girba  a écrit :
> 
> Hi,
> 
> What script are you using?
> 
> Cheers,
> Doru
> 
> 
>> On Nov 24, 2017, at 9:42 AM, Julien  wrote:
>> 
>> Hi,
>> 
>> Thanks for you answer.
>> 
>> I already tried and I do encounter the same issue with #development version.
>> 
>> Julien
>>> Le 24 nov. 2017 à 09:40, Tudor Girba  a écrit :
>>> 
>>> Hi,
>>> 
>>> PetitCompiler is not released for 6.1. Please try with #development and let 
>>> me know if you still encounter the issue.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
 On Nov 24, 2017, at 8:55 AM, Julien  wrote:
 
 Hello,
 
 I’d like to try PetitCompiler to speed-up a parser I did.
 
 When trying to load it in a Pharo 6.1 image I have an error related to its 
 configuration:
 
 Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser';
 configurationOf: #PetitCompiler; load.
 (Smalltalk at: #ConfigurationOfPetitCompiler) perform: #'loadStable'.
 
 « Error : Name not found : Magritte-Tests-Pharo-Model » 
 
 Can someone help me?
 
 I haven't tried in older images.
 
 Julien
>>> 
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>> 
>>> "No matter how many recipes we know, we still value a chef."
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Don't give to get. Just give."
> 
> 
> 
> 
> 
> 
> 

Re: [Pharo-users] Autoupdate of playground contents up to the last keystroke

[Offray Vladimir Luna Cárdenas]

Thanks Doru. Works like a charm.

Cheers,

Offray


On 28/11/17 01:37, Tudor Girba wrote:
> Hi,
>
> You are reading the wrong port.
>
> Try this instead:
>
> playground := GTPlayground new.
> playground openOn: GTPlayPage new.
> playground 
>   onChangeOfPort: #text 
>   act: [ :x | self inform: (x pane port: #text) value ]
>
> Cheers,
> Doru
>
>
>
>> On Nov 28, 2017, at 12:48 AM, Offray Vladimir Luna Cárdenas 
>>  wrote:
>>
>> Hi,
>>
>> Grafoscopio uses Doru's suggestion for auto-updating its contents, as 
>> published in http://ws.stfx.eu/ETEC2JH7363M, but if you test that code you 
>> will see that the contents showed in the inform message are one keystroke 
>> behind of the current playground content, as showed below, which creates 
>> usability issues (we need to add empty spaces and new lines to get the 
>> proper content of the Playground saved).
>>
>> 
>>
>> There is any way to store/show the actual contents of the playground, 
>> instead of one keystroke behind.
>>
>> Thanks,
>>
>> Offray
> --
> www.tudorgirba.com
> www.feenk.com
>
> "We are all great at making mistakes."
>
>
>
>
>
>
>
>
>
>

Re: [Pharo-users] reusing ZnClient session

[Peter Uhnák]

Hi Sven,

yes `session:` would be the ideal solution.
But because it wasn't there (only getter) I wasn't sure whether this was a
design decision - e.g. because sessions can't be reused.

Thanks!
Peter

On Tue, Nov 28, 2017 at 10:51 AM, Sven Van Caekenberghe 
wrote:

> Peter,
>
> > On 28 Nov 2017, at 10:42, Peter Uhnák  wrote:
> >
> > Hi,
> >
> > I have a scenario where I need to login to some web app and then reuse
> the session/cookies in further requests.
> >
> > The basic approach (as presented in Enterprise Pharo book) works just
> fine
> >
> > client := ZnClient new.
> >
> > client
> >   url: 'http://example.com/login';
> >   formAt: 'username' put: 'john@acme.com';
> >   formAt: 'password' put: 'trustno1';
> >   post.
> >
> > client
> >   get: 'http://example.com/my-file'.
> >
> > The problem is when I want to change the way response is retrieved. E.g.
> >
> > client
> >   accept: 'text/json';
> >   contentReader: [ :entity | STON fromString: entity contents ];
> >   get: 'http://example.com/some.json'.
> >
> > "uh-oh... it still uses STON contentReader"
> > client
> >   get: 'http://example.com/homepage.html'
> >
> >
> > Of course I could manually copy all the cookies, however I imagine there
> is a better approach. Maybe injecting session from one ZnClient instance to
> another?
> >
> > Thanks,
> > Peter
>
> Reusing a ZnClient makes most sense when you access one host in a uniform
> way.
>
> Like you say, there are different options
>
>  - reset the content reader when needed (assign nil)
>  - make your content reader more intelligent (check the entity's content
> type and act accordingly)
>  - get the #session from one client and use in on another one (#session:
> must be added for this)
>
> ZnClient holds all kind of state (it is also a builder), so some
> occasional resetting (or managing this state) can be needed.
>
> Does this help ?
>
> Sven
>
>
>

Re: [Pharo-users] files.pharo.org downloads => needs testers

[Peter Uhnák]

What is the relationship between this and http://mirror.pharo.org?

Considering you are already working around these servers, would it be
possible to add HTTPS?


On Tue, Nov 28, 2017 at 5:43 PM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> Hi all,
>
> We set up 2 new servers to replace (at least for some time) the
> problematic files.pharo.org server (slow downloads, bad CRC).
> Please, could you test these new servers and give us feedback to see if
> downloads are fast and nom ore CRC errors?
> * http://file-pharo.inria.fr/
> * http://files2.pharo.org (hosted on the cloud)
>
> Data might be a bit outdated (sync last friday) but is just for testing
> now.
>
> According to your feedbacks, we will switch official URLs to one of these
> servers.
> The situation should be back to normal soon.
>
> Christophe
>

[Pharo-users] files.pharo.org downloads => needs testers

[Christophe Demarey]

Hi all,

We set up 2 new servers to replace (at least for some time) the problematic 
files.pharo.org  server (slow downloads, bad CRC).
Please, could you test these new servers and give us feedback to see if 
downloads are fast and nom ore CRC errors?
* http://file-pharo.inria.fr/
* http://files2.pharo.org (hosted on the cloud)

Data might be a bit outdated (sync last friday) but is just for testing now.

According to your feedbacks, we will switch official URLs to one of these 
servers.
The situation should be back to normal soon.

Christophe

Re: [Pharo-users] I love the launcher!!!!

[Christophe Demarey]

Hi Phil,

> Le 26 nov. 2017 à 22:25, p...@highoctane.be a écrit :
> 
> So, I try it on my CentOS 7 64 bit and... as there is no 64 bit version of 
> the launcher…

Right.
Can’t you use the 32 bit version?
Anyway, I think it would be good to have a 64 bit version.  Could you open an 
issue for that please?

> 
> pharo6-64-ui PharoLauncher.image 
> This interpreter (vers. 68021) cannot read image file (vers. 6521).
> Press CR to quit...
> 
> How is one using the launcher for 64 bit stuff?
> 
> Phil
> 
> On Sun, Nov 26, 2017 at 9:45 PM, Stephane Ducasse  > wrote:
> If you don't try you will not understand what you miss.
> 
> On Sun, Nov 26, 2017 at 2:10 PM, Herby Vojčík  > wrote:
> > Stephane Ducasse wrote:
> >>
> >> Then do not try :) like that you will never get a chance to know :)
> >
> >
> > Could you please explain? I understood your sentence has high dose of homour
> > which I cannot decipher since I lack certain abilities for that.
> >
> > Thanks, Herby
> >
> >> Stef
> >>
> >>
> >> On Sun, Nov 26, 2017 at 1:48 PM, Herby Vojčík >> >  wrote:
> >>>
> >>> Stephane Ducasse wrote:
> 
>  Why don't you try? It does not bite.
> 
>  For me it works in all scenario. I have projects that i manage over
>  several weeks and others I drop day to day.
>  And I have also startup script per versions.
> >>>
> >>>
> >>> Maybe I will. The main problem was I didn't what it's good about at all -
> >>> load image for a version, runs it - what's the "wow it's great" about?
> >>> Missed part was it loads correct vm; plus makes sense when you have
> >>> hundreds
> >>> (I don't). Now it must be combined with the startup script magic to work
> >>> with long-time projects, but those are also new to me - did not know of
> >>> them
> >>> until your booklet, not using them at all yet.
> >>>
> >>> Herby
> >>>
> >>>
>  Stef
> 
>  On Fri, Nov 24, 2017 at 3:10 PM, Herby Vojčík  >   wrote:
> >
> > Thank you all, now I understand it better. Good for lots of "branches".
> >
> > However, I wonder how does it work with the rule I read somewhere:
> > "start
> > each day [of work on a project] with a new image", which means I should
> > not
> > reuse clean new image (as it needs populating from VCSes etc.) nor
> > reuse
> > existing image (I should start with the new one). Or does it combine
> > with
> > some startup-magic described in one of the recent Steph's booklets, the
> > "one
> > start per [new] image" case (but again, one should discriminate
> > projects
> > from each other)?
> >
> > Thanks, Herby
> >
> > Peter Uhnák wrote:
> >>
> >> Hi Herby,
> >>
> >> normally people use different images for their different projects,
> >> different versions, trying things, etc. Which means we end up with
> >> many
> >> locations on disk, and it can be hard to track.
> >> So PharoLauncher is a nice tool where you can download fresh image
> >> just
> >> by clicking, and you see the list of your local images and can launch
> >> them, etc.
> >>
> >> Peter
> >>
> >> On Thu, Nov 23, 2017 at 12:56 PM, Herby Vojčík >> 
> >> >>   wrote:
> >>
> >>   Stephane Ducasse wrote:
> >>
> >>   Hi
> >>
> >>   I love the PharoLauncher.
> >>
> >>
> >>   Pardon my question, I have downloaded it and looked at it, but I
> >>   don't get it. What does it do / what are the use cases (honest
> >>   question)?
> >>
> >>   Thanks, Herby
> >>
> >>
> >>   It helps me to manage my parallel development and projects.
> >>
> >>   We should put a link on the Pharo web site because
> >>
> >>   http://files.pharo.org/platform/launcher/ 
> >> 
> >>    >> >
> >>
> >>   is arcane.
> >>
> >>   Stef
> >>
> >>
> >>
> >>
> >>>
> >>
> >
> >
> 
> 
> 

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Mariano Martinez Peck]

On Tue, Nov 28, 2017 at 10:20 AM, Sven Van Caekenberghe 
wrote:

>
>
> > On 28 Nov 2017, at 13:52, Mariano Martinez Peck 
> wrote:
> >
> >
> >
> > On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck 
> wrote:
> > Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck:
> > > Hi Andreas,
> > >
> > > Do you know why method contexts are trying to be serialized? Of course,
> > > probably because of closures.  Do you think / know / are aware of
> closures
> > > as part of your graph? Maybe Sorted Collection?
> > > I am asking because if the only thing is SortedCollection then we can
> use
> > > some hook...
> >
> > I have closures in several places in the object graph. These are objects
> > with some pluggable functionality, which I rely on.
> >
> >
> > OK. The question is then if those closures are "clean" or not. In other
> words, what's their scope? Do they refer to variables defined outside  the
> closure (in which case you would need the methods contexts / stack) or are
> they clean in the sense that you could be able to replace them via a string
> and then compile them again ?
> > Some time ago we added a #isClean to BlockClosure. You can test a few of
> your closures to see if this is the case or not.
> >
> > Btw, I have an application for a client in which we also have closures
> to define some pluggable behavior. But what I do is:
> >
> > 1) guarantee they are 100% clean (does not go outside of scope)
> > 2) aside from the "block" instVar I also add another instVar which is
> the "string" version of it. Then I always implement #
> fuelIgnoredInstanceVariableNames to ignore all those "block" instVars,
> yet DO NOT ignore the "string" like of those closures. Then, of course, the
> getter of the block instvar does a lazy compilation if the block instVar is
> nil...
>
> Ah, that's cheating ;-)
>


I didn't say it wasn't hahahahahaha


>
> But totally acceptable with clean blocks.
>
> So,
>
> [ :x :y | x < y ] isClean.
>
>   => true
>
> [ :x :y | x < y ] sourceNode formattedCode.
>
>   => '[ :x :y | x < y ]'
>
> But
>
> Compiler evaluate: '[ :x :y | x < y ]'.
>
>   => [ :arg1 :arg2 | arg1 < arg2 ]
>
> So the argument names get lost, which seems like a pity. How are you doing
> it ? Can it be done differently ?
>
>

I really don't care at all how closures look like. The idea is: always keep
the string version instVars and sixx/fuel ignore the block version. block
version getter compiles from string if nil.
I think you might have understood I use the same instVar and that sometimes
I set a string and sometimes I set a closure. If that's the case, then yes,
I ended up with 2 different instVars...


Example:


FaAction class >> fuelIgnoredInstanceVariableNames
^ #('actionBlock')


FaPersistentObject subclass: #FaAction
instanceVariableNames: 'action actionBlock'
classVariableNames: ''
package: 'FA-Core'


FaAction  >> actionBlock
^ actionBlock
ifNil: [ action isEmptyOrNil
ifTrue: [ nil ]
ifFalse: [actionBlock := self compile: action ] ]

That's is obviously a simplified example and it might have some syntax
error but I guess you get the idea, right?


So this has worked very well for me with Fuel on Pharo and Sixx on
GemStone. There are obvious drawbacks like: it only works for clean
closures, having to have 2 instVar per "concept" , have to compile when I
only have the string, etc etc.






> > I know you already have your application written, but I am trying to
> explain how I was able to use Fuel for this case...
> >
> >
> > Just for my better understanding, I like to ask: The FLMethodChanged
> > errors will show up for *EVERY* method of a materialized object (Since
> > the bytecodesHash changed for every method) or just those methods which
> > involve fuel-persisted MethodContexts? (Sorry, if the question is
> > stupid, but I am rather new to Fuel internals)
> >
> >
> > As far as I can remember, the latter.
> >
> >
> >
> >
> > Cheers,
> > Andreas
> >
> > --
> > Andreas Brodbeck
> > www.mindclue.ch
> >
> >
> >
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Sven Van Caekenberghe]

> On 28 Nov 2017, at 13:52, Mariano Martinez Peck  wrote:
> 
> 
> 
> On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck  wrote:
> Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck:
> > Hi Andreas,
> >
> > Do you know why method contexts are trying to be serialized? Of course,
> > probably because of closures.  Do you think / know / are aware of closures
> > as part of your graph? Maybe Sorted Collection?
> > I am asking because if the only thing is SortedCollection then we can use
> > some hook...
> 
> I have closures in several places in the object graph. These are objects
> with some pluggable functionality, which I rely on.
> 
> 
> OK. The question is then if those closures are "clean" or not. In other 
> words, what's their scope? Do they refer to variables defined outside  the 
> closure (in which case you would need the methods contexts / stack) or are 
> they clean in the sense that you could be able to replace them via a string 
> and then compile them again ? 
> Some time ago we added a #isClean to BlockClosure. You can test a few of your 
> closures to see if this is the case or not. 
> 
> Btw, I have an application for a client in which we also have closures to 
> define some pluggable behavior. But what I do is:
> 
> 1) guarantee they are 100% clean (does not go outside of scope) 
> 2) aside from the "block" instVar I also add another instVar which is the 
> "string" version of it. Then I always implement 
> #fuelIgnoredInstanceVariableNames to ignore all those "block" instVars, yet 
> DO NOT ignore the "string" like of those closures. Then, of course, the 
> getter of the block instvar does a lazy compilation if the block instVar is 
> nil...

Ah, that's cheating ;-) 

But totally acceptable with clean blocks.

So,

[ :x :y | x < y ] isClean.

  => true

[ :x :y | x < y ] sourceNode formattedCode.

  => '[ :x :y | x < y ]'

But

Compiler evaluate: '[ :x :y | x < y ]'.

  => [ :arg1 :arg2 | arg1 < arg2 ]

So the argument names get lost, which seems like a pity. How are you doing it ? 
Can it be done differently ?

> I know you already have your application written, but I am trying to explain 
> how I was able to use Fuel for this case... 
>  
> 
> Just for my better understanding, I like to ask: The FLMethodChanged
> errors will show up for *EVERY* method of a materialized object (Since
> the bytecodesHash changed for every method) or just those methods which
> involve fuel-persisted MethodContexts? (Sorry, if the question is
> stupid, but I am rather new to Fuel internals)
> 
> 
> As far as I can remember, the latter. 
> 
> 
>  
> 
> Cheers,
> Andreas
> 
> --
> Andreas Brodbeck
> www.mindclue.ch
> 
> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Mariano Martinez Peck]

On Tue, Nov 28, 2017 at 9:20 AM, Andreas Brodbeck  wrote:

> Am 28.11.17 um 11:13 schrieb H. Hirzel:
> > Hello Andreas
> >
> > Unfortunately Fuel is not meant for this kind of use case of migrating
> > an object model.
>
> That's sad to hear. From 1.4 to 6.1 is a big step, I agree, but I really
> thought that Fuel can be considered as a good "transport vehicle" at
> least for small steps like from Pharo 5 to 6.
>
>

Yes, watching it from now, I think this was our biggest drawback of fuel.




> >
> > So other options have to be considered.
>
> That probably would be a custom mechanism storing objects in a database
> or fileformat and re-import, I think. Lots of work and very error prone.
> But maybe the only way unfortunately ...
>
> SIXX would be an option you think?
>
>

No. SIXX doesn't know how to deal with closures.




> >
> > Does your object model have cycles?
>
> Yes.
>
>
> Regards,
> Andreas
>
> --
> Andreas Brodbeck
> www.mindclue.ch
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Mariano Martinez Peck]

On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck  wrote:

> Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck:
> > Hi Andreas,
> >
> > Do you know why method contexts are trying to be serialized? Of course,
> > probably because of closures.  Do you think / know / are aware of
> closures
> > as part of your graph? Maybe Sorted Collection?
> > I am asking because if the only thing is SortedCollection then we can use
> > some hook...
>
> I have closures in several places in the object graph. These are objects
> with some pluggable functionality, which I rely on.
>


*OK. The question is then if those closures are "clean" or not.* In other
words, what's their scope? Do they refer to variables defined outside  the
closure (in which case you would need the methods contexts / stack) or are
they clean in the sense that you could be able to replace them via a string
and then compile them again ?
Some time ago we added a #isClean to BlockClosure. You can test a few of
your closures to see if this is the case or not.

Btw, I have an application for a client in which we also have closures to
define some pluggable behavior. But what I do is:

1) guarantee they are 100% clean (does not go outside of scope)
2) aside from the "block" instVar I also add another instVar which is the
"string" version of it. Then I always implement
#fuelIgnoredInstanceVariableNames to ignore all those "block" instVars, yet
DO NOT ignore the "string" like of those closures. Then, of course, the
getter of the block instvar does a lazy compilation if the block instVar is
nil...

I know you already have your application written, but I am trying to
explain how I was able to use Fuel for this case...


>
> Just for my better understanding, I like to ask: The FLMethodChanged
> errors will show up for *EVERY* method of a materialized object (Since
> the bytecodesHash changed for every method) or just those methods which
> involve fuel-persisted MethodContexts? (Sorry, if the question is
> stupid, but I am rather new to Fuel internals)
>
>
As far as I can remember, the latter.




>
> Cheers,
> Andreas
>
> --
> Andreas Brodbeck
> www.mindclue.ch
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Andreas Brodbeck]

Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck:
> Hi Andreas,
> 
> Do you know why method contexts are trying to be serialized? Of course,
> probably because of closures.  Do you think / know / are aware of closures
> as part of your graph? Maybe Sorted Collection?
> I am asking because if the only thing is SortedCollection then we can use
> some hook...

I have closures in several places in the object graph. These are objects
with some pluggable functionality, which I rely on.

Just for my better understanding, I like to ask: The FLMethodChanged
errors will show up for *EVERY* method of a materialized object (Since
the bytecodesHash changed for every method) or just those methods which
involve fuel-persisted MethodContexts? (Sorry, if the question is
stupid, but I am rather new to Fuel internals)


Cheers,
Andreas

-- 
Andreas Brodbeck
www.mindclue.ch

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Sean P. DeNigris]

Andreas Brodbeck-3 wrote
>> So other options have to be considered.
> 
> That probably would be a custom mechanism storing objects in a database
> or fileformat and re-import,…

My two primary workarounds in this scenario are:
1. Try STON
2. Try Fuel in smaller hops (e.g. 1.4 -> 2 -> 4, etc), although I'm not sure
that would work in your case. This seemed more useful when I didn't seem
able to load the same version of Fuel in the source and target.

Here is a little working document that might help get you started:
https://github.com/seandenigris/pharo/wiki/Data-Migration



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

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Andreas Brodbeck]

Am 28.11.17 um 11:13 schrieb H. Hirzel:
> Hello Andreas
> 
> Unfortunately Fuel is not meant for this kind of use case of migrating
> an object model.

That's sad to hear. From 1.4 to 6.1 is a big step, I agree, but I really
thought that Fuel can be considered as a good "transport vehicle" at
least for small steps like from Pharo 5 to 6.

> 
> So other options have to be considered.

That probably would be a custom mechanism storing objects in a database
or fileformat and re-import, I think. Lots of work and very error prone.
But maybe the only way unfortunately ...

SIXX would be an option you think?

> 
> Does your object model have cycles?

Yes.


Regards,
Andreas

-- 
Andreas Brodbeck
www.mindclue.ch

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Mariano Martinez Peck]

Hi Andreas,

Do you know why method contexts are trying to be serialized? Of course,
probably because of closures.  Do you think / know / are aware of closures
as part of your graph? Maybe Sorted Collection?
I am asking because if the only thing is SortedCollection then we can use
some hook...

Let me know,

On Tue, Nov 28, 2017 at 7:01 AM, Andreas Brodbeck  wrote:

> Hi all,
>
> I have a long running Seaside/Pharo application which still runs perfect
> on Pharo 1.4. I want to step into the future and migrate to the newest
> Pharo 6.1.
>
> The application's persistence is just in the image, so my plan is to use
> Fuel to transfer the objects from Pharo 1.4 to Pharo 6.1.
>
> My first attempt:
>
> --- Using Fuel version 1.9.4 on both VMs.
> --- Class TimeStamp was missing, so I created it.
> --- I use a Fuel-migration for the renaming of "MethodContext" into the
> new "Context" class.
>
>
> But now I am stuck with FLMethodChanged errors. My investigation shows
> that there are unequal values for the method Context>>bytecodesHash when
> comparing Pharo 1.4 with 6.1. (BTW: Pharo 5 gives same values like 6.1).
>
> So, basically Fuel can not materialize the instances because the
> bytecode hash of all methods have changed, comparing 1.4 to 6.1. My
> feeling says that this could be a major problem for my plans to migrate
> from Pharo 1.4 to 6.1.
>
> Is there a chance to still load those instances with Fuel into the new
> 6.1 Pharo?
>
> Thanks!
> Andreas
>
> --
> Andreas Brodbeck
> www.mindclue.ch
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[stephan]

On 28-11-17 11:01, Andreas Brodbeck wrote:

So, basically Fuel can not materialize the instances because the
bytecode hash of all methods have changed, comparing 1.4 to 6.1. My
feeling says that this could be a major problem for my plans to migrate
from Pharo 1.4 to 6.1.


If you export the bytecode hash of the 1.4 methods, you might be able to 
use those to materialize again in 6.1. Or at least get a step further, 
as there will be more things new & renamed & missing.


Stephan

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[H. Hirzel]

Hello Andreas

Unfortunately Fuel is not meant for this kind of use case of migrating
an object model.

So other options have to be considered.

Does your object model have cycles?

Regards
Hannes

On 11/28/17, Andreas Brodbeck  wrote:
> Hi all,
>
> I have a long running Seaside/Pharo application which still runs perfect
> on Pharo 1.4. I want to step into the future and migrate to the newest
> Pharo 6.1.
>
> The application's persistence is just in the image, so my plan is to use
> Fuel to transfer the objects from Pharo 1.4 to Pharo 6.1.
>
> My first attempt:
>
> --- Using Fuel version 1.9.4 on both VMs.
> --- Class TimeStamp was missing, so I created it.
> --- I use a Fuel-migration for the renaming of "MethodContext" into the
> new "Context" class.
>
>
> But now I am stuck with FLMethodChanged errors. My investigation shows
> that there are unequal values for the method Context>>bytecodesHash when
> comparing Pharo 1.4 with 6.1. (BTW: Pharo 5 gives same values like 6.1).
>
> So, basically Fuel can not materialize the instances because the
> bytecode hash of all methods have changed, comparing 1.4 to 6.1. My
> feeling says that this could be a major problem for my plans to migrate
> from Pharo 1.4 to 6.1.
>
> Is there a chance to still load those instances with Fuel into the new
> 6.1 Pharo?
>
> Thanks!
> Andreas
>
> --
> Andreas Brodbeck
> www.mindclue.ch
>
>
>

[Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

[Andreas Brodbeck]

Hi all,

I have a long running Seaside/Pharo application which still runs perfect
on Pharo 1.4. I want to step into the future and migrate to the newest
Pharo 6.1.

The application's persistence is just in the image, so my plan is to use
Fuel to transfer the objects from Pharo 1.4 to Pharo 6.1.

My first attempt:

--- Using Fuel version 1.9.4 on both VMs.
--- Class TimeStamp was missing, so I created it.
--- I use a Fuel-migration for the renaming of "MethodContext" into the
new "Context" class.


But now I am stuck with FLMethodChanged errors. My investigation shows
that there are unequal values for the method Context>>bytecodesHash when
comparing Pharo 1.4 with 6.1. (BTW: Pharo 5 gives same values like 6.1).

So, basically Fuel can not materialize the instances because the
bytecode hash of all methods have changed, comparing 1.4 to 6.1. My
feeling says that this could be a major problem for my plans to migrate
from Pharo 1.4 to 6.1.

Is there a chance to still load those instances with Fuel into the new
6.1 Pharo?

Thanks!
Andreas

-- 
Andreas Brodbeck
www.mindclue.ch

Re: [Pharo-users] reusing ZnClient session

[Sven Van Caekenberghe]

Peter,

> On 28 Nov 2017, at 10:42, Peter Uhnák  wrote:
> 
> Hi,
> 
> I have a scenario where I need to login to some web app and then reuse the 
> session/cookies in further requests.
> 
> The basic approach (as presented in Enterprise Pharo book) works just fine
> 
> client := ZnClient new.
> 
> client
>   url: 'http://example.com/login';
>   formAt: 'username' put: 'john@acme.com';
>   formAt: 'password' put: 'trustno1';
>   post.
> 
> client 
>   get: 'http://example.com/my-file'.
> 
> The problem is when I want to change the way response is retrieved. E.g.
> 
> client
>   accept: 'text/json';
>   contentReader: [ :entity | STON fromString: entity contents ];
>   get: 'http://example.com/some.json'.
> 
> "uh-oh... it still uses STON contentReader"
> client
>   get: 'http://example.com/homepage.html'
> 
> 
> Of course I could manually copy all the cookies, however I imagine there is a 
> better approach. Maybe injecting session from one ZnClient instance to 
> another?
> 
> Thanks,
> Peter

Reusing a ZnClient makes most sense when you access one host in a uniform way.

Like you say, there are different options

 - reset the content reader when needed (assign nil)
 - make your content reader more intelligent (check the entity's content type 
and act accordingly)
 - get the #session from one client and use in on another one (#session: must 
be added for this)

ZnClient holds all kind of state (it is also a builder), so some occasional 
resetting (or managing this state) can be needed.

Does this help ?

Sven

[Pharo-users] reusing ZnClient session

[Peter Uhnák]

Hi,

I have a scenario where I need to login to some web app and then reuse the
session/cookies in further requests.

The basic approach (as presented in Enterprise Pharo book) works just fine

client := ZnClient new.

client
url: 'http://example.com/login';
formAt: 'username' put: 'john@acme.com';
formAt: 'password' put: 'trustno1';
post.

client
get: 'http://example.com/my-file'.

The problem is when I want to change the way response is retrieved. E.g.

client
accept: 'text/json';
contentReader: [ :entity | STON fromString: entity contents ];
get: 'http://example.com/some.json'.

"uh-oh... it still uses STON contentReader"
client
get: 'http://example.com/homepage.html'


Of course I could manually copy all the cookies, however I imagine there is
a better approach. Maybe injecting session from one ZnClient instance to
another?

Thanks,
Peter

Re: [Pharo-users] How to write a little REPL

[Clément Bera]

 There is a REPL Image we use for VM debugging. It's a REPL in the command
line and in the VM Simulator.

File-in in attachement to load and start the REPL.

On Tue, Nov 28, 2017 at 8:18 AM, Stephane Ducasse 
wrote:

> Sorry I wanted to have it in pharo :)
>
> On Mon, Nov 27, 2017 at 3:56 AM, Holger Freyther 
> wrote:
> >
> >> On 27. Nov 2017, at 05:38, Stephane Ducasse 
> wrote:
> >>
> >> Hi
> >
> > Hey!
> >
> >
> >> I'm working on a mini scheme implementation and I would like to add a
> REPL and
> >> I wonder how I can super easily get a read line.
> >
> > The easiest might just be to use "rlwrap your-interpreter"? But I think
> you want to allow multi-line input. So either link libreadline (GPL) or
> libedit?
> >
> > holger
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq


StartReader.st
Description: Binary data


LoadReader.st
Description: Binary data

Re: [Pharo-users] How to write a little REPL

[Alistair Grant]

On 28 November 2017 at 08:18, Stephane Ducasse  wrote:
> Sorry I wanted to have it in pharo :)

Are you talking about having a terminal inside Pharo?

OSProcess included something like this, i.e. open the window and have
a prompt where you can enter expressions to be evaluated.  It would
also run external processes and capture the output.

Cheers,
Alistair


> On Mon, Nov 27, 2017 at 3:56 AM, Holger Freyther  wrote:
>>
>>> On 27. Nov 2017, at 05:38, Stephane Ducasse  wrote:
>>>
>>> Hi
>>
>> Hey!
>>
>>
>>> I'm working on a mini scheme implementation and I would like to add a REPL 
>>> and
>>> I wonder how I can super easily get a read line.
>>
>> The easiest might just be to use "rlwrap your-interpreter"? But I think you 
>> want to allow multi-line input. So either link libreadline (GPL) or libedit?
>>
>> holger
>