[Pharo-dev] Re: Platform Packages vs. Git Branches

[Max Leske]

On 29 Aug 2022, at 18:25, Dale Henrichs wrote:

> Max,
>
> Yeah, your approach looks manageable ... with a well defined common code
> base, both branch per platform (fuel) and platform packages (Grease) can be
> used ...
>
> I looked at your github action code and see that you've got a solution for
> triggering multi-branch runs ... workflow per branch/platform ... so I will
> HAVE TO CONSIDER the branch per platform approach again :)

Yeah, not perfect, but it works (reusability isn't a focus of GitHub 
workflows...).

>
> Dale
>
> On Mon, Aug 29, 2022 at 8:53 AM Max Leske  wrote:
>
>> Hi Sean,
>>
>> At some point you will probably come to the same point that Seaside and
>> Fuel have reached in the past: build your own abstraction layer (Grease in
>> Seaside, Fuel-Platform in Fuel). There are valid arguments against this
>> approach but, personally, I didn't have another choice for Fuel.
>>
>> Fuel setup:
>>
>>- A Fuel-Plaform-Core package
>>- 1 Fuel-Platform package per dialect and version
>>- development branch, old "release" branch, current "release" branch
>>for Fuel-Platform
>>- 1 Git branch for Fuel per version
>>- some magic in the baselines to get Metacello to load what I want
>>
>> I used to have the same multiple package approach that you mentioned but
>> it fell apart when I had too many packages with too many differences.
>>
>> Cheers,
>> Max
>>
>> On 25 Aug 2022, at 16:16, s...@clipperadams.com wrote:
>>
>> I’ve always supported multiple platforms (e.g. different Pharo versions)
>> via packages like MyProject-Plaform-Pharo9. Thinking back, the primary
>> reason is that is how I saw it done by other projects. Also, I adopted the
>> practice well before git was in wide use in the Pharo world.
>> However, Jan Bliznicenko recently suggested an alternate workflow which
>> sounds like how Pharo itself is managed: use git branches, with the primary
>> branch supporting only latest Pharo, and other branches only getting
>> critical bug fixes backported.
>> Not sure how that would work for projects that support other dialects e.g.
>> Gemstone and Squeak, since there would then be multiple “latest versions”.
>> I’m interested in opinions about these options as I feel that Magritte is
>> an important community asses and want to keep it compatible on as many
>> platforms as possible (with as little work as possible)! I also get the
>> feeling that many people keep ancient systems in production, and I wonder
>> which they would prefer - a project that is stable on a Pharo version (more
>> or less) when that version is released or having the latest commits,
>> especially bug fixes.
>> Thoughts?
>>
>>



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Re: Platform Packages vs. Git Branches

[Max Leske]

Hi Sean,

At some point you will probably come to the same point that Seaside and Fuel 
have reached in the past: build your own abstraction layer (Grease in Seaside, 
Fuel-Platform in Fuel). There are valid arguments against this approach but, 
personally, I didn't have another choice for Fuel.

Fuel setup:
- A Fuel-Plaform-Core package
- 1 Fuel-Platform package per dialect and version
- development branch, old "release" branch, current "release" branch for 
Fuel-Platform
- 1 Git branch for Fuel per version
- some magic in the baselines to get Metacello to load what I want

I used to have the same multiple package approach that you mentioned but it 
fell apart when I had too many packages with too many differences.

Cheers,
Max


On 25 Aug 2022, at 16:16, s...@clipperadams.com wrote:

> I’ve always supported multiple platforms (e.g. different Pharo versions) via 
> packages like MyProject-Plaform-Pharo9. Thinking back, the primary reason is 
> that is how I saw it done by other projects. Also, I adopted the practice 
> well before git was in wide use in the Pharo world.
>
> However, Jan Bliznicenko recently suggested an alternate workflow which 
> sounds like how Pharo itself is managed: use git branches, with the primary 
> branch supporting only latest Pharo, and other branches only getting critical 
> bug fixes backported.
>
> Not sure how that would work for projects that support other dialects e.g. 
> Gemstone and Squeak, since there would then be multiple “latest versions”.
>
> I’m interested in opinions about these options as I feel that Magritte is an 
> important community asses and want to keep it compatible on as many platforms 
> as possible (with as little work as possible)! I also get the feeling that 
> many people keep ancient systems in production, and I wonder which they would 
> prefer - a project that is stable on a Pharo version (more or less) when that 
> version is released or having the latest commits, especially bug fixes.
>
> Thoughts?


signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Re: [ANN] Fuel 5.0.0

[Max Leske]

On 28 Feb 2022, at 20:55, Marcus Denker wrote:

>>>
>>> Fuel for now just ignores the whole “First class Variable” concept and 
>>> serialises the “raw” view of indexed instance
>>> variables… (which is the right thing to do now), but that would not work 
>>> here anymore.
>>
>> Good to know. I'll have to think about how this plays together with the 
>> "classic" architecture.
>>
>
>
> This is why I am in general not a fan of this idea of code trying to be 
> compatible on that level…
>
> To me what fascinated me about Squeak was not to be slavishly compatible to 
> ST80, but to do
> and do *more*. To take the philosophy and push it further… but that can *not* 
> be done if one
> want to 100% backward compatible on an implementation level forever...
>
> I think my next talk at ESUG will be “Why I am not a Smalltalker”. :-)

lol :D

I know what you mean. I'll have to see what happens with Squeak 6. Maybe we'll 
reach a point where it becomes easier to maintain
two separate versions. As long as there are users in Squeak I want to support 
them (maybe I'll do a survey
in the Squeak community at that point, it could also be an option to drop 
support for Squeak if they don't
use Fuel).

>
>   Marcus

signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Re: [ANN] Fuel 5.0.0

[Max Leske]

On 28 Feb 2022, at 9:27, Marcus Denker wrote:

>> On 27 Feb 2022, at 19:34, Max Leske  wrote:
>>
>> Hi everyone,
>>
>> I'm happy to announce Fuel version 5.0.0 today.
>>
>> The changes to 4.0.0 aren't huge but I've had to adjust the format once more.
>>
>> 5.0.0 comes with full support for stateful traits, i.e. traits with instance 
>> variables. You can find the release notes here: 
>> https://theseion.github.io/Fuel/releases/5.0.0/.
>>
>
> Nice! As soon as the Pharo11 dev cycle starts, I want to use it and look into 
> the state of serialising clean blocks.
>
> (Clean blocks are not enabled by default in Pharo10, but I want to push for 
> finishing that soon in Pharo11).

That's going to be interesting :). Ideally this will work out of the box.

>
> Another change I am looking into is to allow Slots on all classes… we can not 
> not have indexed instance variables
> in some classes, but with Slots we can define non-indexed “instance 
> variables” that store somewhere else.
>
> E.g. we could implement a subclass of Slot that would realise a Variable 
> “source” on CompiledMethod that would
> abstract away source code storage mess (just as an example what this can do, 
> not to say that we should do exactly that).
>
> Or have a Slot that stores into a property API as we have it on all the 
> Structural entities (from classes down to compiledMethod).
>
> Fuel for now just ignores the whole “First class Variable” concept and 
> serialises the “raw” view of indexed instance
> variables… (which is the right thing to do now), but that would not work here 
> anymore.

Good to know. I'll have to think about how this plays together with the 
"classic" architecture.

>
>   Marcus

signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Re: Talents - VM Crash on P9 after Fuel Materialization

[Max Leske]

Hi Sean,

I would assume that it's a Fuel issue. I've opened an issue on GitHub: 
https://github.com/theseion/Fuel/issues/262

Cheers,
Max


On 24 Feb 2022, at 17:32, s...@clipperadams.com wrote:

> After serializing and then materializing an object with a talent, the trait's 
> instVar seems to have disappeared from the inspector, although the print 
> string looks like that of a Talented object. If you send a getter for a 
> talented ivar, Pharo crashes. Not sure if this is a Talents problem or a Fuel 
> problem (or both).
>
> More details and reproducible steps here: 
> [https://github.com/tesonep/pharo-talents/issues/11]( 
> https://github.com/tesonep/pharo-talents/issues/11 " 
> https://github.com/tesonep/pharo-talents/issues/11;)
>
> Anyone have some insight?\
> \
> I reported on Jan 7, but maybe more eyeballs here.
>
> I’ve been eager to give Talents a real try, but use Fuel extensively, so this 
> is a blocking issue for me.



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Re: PTerm - Can't Find FFI Library on M1 Mac on P9

[Max Leske]

Hey Sean,

I can get a terminal to open (with a bit of manual intervention) and I can type 
some characters. So FFI calls appear to work but the application is pretty 
broken on P9.

This is on a x86 MacBook Pro. Simply added the repo in Iceberg and loaded the 
baseline.


Cheers,
Max

On 24 Feb 2022, at 17:35, s...@clipperadams.com wrote:

> The really cool PTerm in-image terminal emulator works for me in P8 but not 
> on P9. I recently upgraded to an M1 Mac, so I’m trying to isolate whether ARM 
> is the cause of the problem.
>
> Can someone try to reproduce the issue described here: 
> [https://github.com/lxsang/PTerm/issues/20](https://github.com/lxsang/PTerm/issues/20
>  "https://github.com/lxsang/PTerm/issues/20;)
>
> TIA,
>
> s



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Re: Fuel projects, anyone?

[Max Leske]

Thanks Gabriel, that's great!

I've added Launchpad to the list.



On 27 May 2021, at 22:15, Gabriel Cotelli wrote:

> We're using Fuel to serialize the stack on unexpected errors to ease
> further debugging. See
> https://github.com/ba-st/Launchpad/blob/release-candidate/source/Launchpad/ErrorStackSerializer.class.st.
>
> So any project using ba-st/Launchpad <https://github.com/ba-st/Launchpad>
> is indirectly using Fuel. For the record, the Pharo components running in
> the backend of https://mercapabbaco.com are using this technique.
>
> Cheers,
> Gabriel
>
> On Thu, May 27, 2021 at 5:09 PM Max Leske  wrote:
>
>> Hi everyone,
>>
>> I was made aware that there actually *are* people who use Fuel :) I
>> rarely get feedback, apart from the spare bug report, so I was thrilled to
>> hear about people who use it actively or even have applications in
>> production that rely on Fuel.
>>
>> To celebrate that (and boost my own ego of course...) I've added a
>> "Projects using Fuel" section to the readme on GitHub and I'd love to see
>> more entries in that list! So please let me know (or open a PR!) if you
>> think your project deserves some exposure ;)
>>
>> Here's the link: https://github.com/theseion/Fuel.
>>
>> Stay awesome and positive!
>>
>> Cheers,
>> Max
>>



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Fuel for Pharo 9 on the way

[Max Leske]

Hi

Just wanted to give you a heads up that I'm working on a new release of Fuel 
for Pharo 9. Should be done soon.

Is there still time to get it integrated or are we in hard freeze already (the 
currently loaded version has several test failures)?


Cheers,
Max

signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Pharogenesis?

[Max Leske]

Hi Michael,

That's my project :) This is the link to the repository: 
https://github.com/theseion/pharogenesis.

I should have all the sources etc. if you need anything else.


Cheers,
Max


On 14 May 2020, at 3:59, Michael Rueger wrote:

> Hi all,
>
> after digging out some old pet project about an archive of historical 
> Smalltalk code I came across the Pharogenesis project 
> (http://scg.unibe.ch/research/Pharogenesis).
> The git link is unfortunately dead, any chance somebody still has a fork/copy?
>
> The source code is still up on SqueakSource, but probably not really useful 
> with the git repo?
>
> Cheers
>
> Michael


signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] FullBlockClosure - How to create one...

[Max Leske]

Oh, interesting! I did not know that, thanks Eliot.




On 1 May 2020, at 18:49, Eliot Miranda wrote:

> Hi Max,
>
> On Thu, Apr 30, 2020 at 11:51 PM Max Leske  wrote:
>
>> Hi Sean,
>>
>> You *need* an outer context. See Context>>cleanCopy, which Fuel uses to
>> serialize blocks.
>>
>
> One does *not* need an outer context.  An outer context of nil should be
> fine, provided that the block never attempts an up-arrow return.
>
>
> | blockMethod |
> blockMethod := [:a :b| a < b] method.
> (FullBlockClosure receiver: nil outerContext: nil method: blockMethod
> copiedValues: nil) value: 1 value: 2
>
> So one needs to use FullBlockClosure
> class>>receiver:outerContext:method:copiedValues: and one can supply nil
> for the outerContext provided that the block does not do an up-arrow return.
>
>
>> Cheers,
>> Max
>>
>> On 1 May 2020, at 3:23, Sean P. DeNigris wrote:
>>
>> What am I not understanding about FullBlockClosure?
>>
>> I have a clean block that I'd like to turn into a FullBlockClosure so that
>> I
>> can serialize it without dragging (unneeded methods) into my object graph.
>> However, documentation and in-image example usages seem severely limited.
>> Here was one experiment that ended with a primitive failure. It seems like
>> a
>> receiver is needed and it can't be a dummy value (see commented "receiver:
>> 1"). But what would the receiver be in the absence of an outer context?!
>>
>> aBlockClosure := [ :a :b | 1 + a + b ].
>> fbc := (FullBlockClosure
>> outerContext: nil
>> startpc: aBlockClosure startpc
>> numArgs: aBlockClosure argumentCount
>> copiedValues: Array new) "receiver: 1; yourself".
>>
>> fbc value: 2 value: 3. "PrimitiveFailed: primitive #value:value: in
>> FullBlockClosure failed"
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>>
>
> -- 
> _,,,^..^,,,_
> best, Eliot




signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] FullBlockClosure - How to create one...

[Max Leske]

Hi Sean,

You *need* an outer context. See Context>>cleanCopy, which Fuel uses to 
serialize blocks.


Cheers,
Max

On 1 May 2020, at 3:23, Sean P. DeNigris wrote:

> What am I not understanding about FullBlockClosure?
>
> I have a clean block that I'd like to turn into a FullBlockClosure so that I
> can serialize it without dragging (unneeded methods) into my object graph.
> However, documentation and in-image example usages seem severely limited.
> Here was one experiment that ended with a primitive failure. It seems like a
> receiver is needed and it can't be a dummy value (see commented "receiver:
> 1"). But what would the receiver be in the absence of an outer context?!
>
> aBlockClosure := [ :a :b  | 1 + a + b ].
> fbc := (FullBlockClosure
>   outerContext: nil
>   startpc: aBlockClosure startpc
>   numArgs: aBlockClosure argumentCount
>   copiedValues: Array new) "receiver: 1; yourself".
>
> fbc value: 2 value: 3. "PrimitiveFailed: primitive #value:value: in
> FullBlockClosure failed"
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html


signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Programmatically change display size in Pharo 8 / 9

[Max Leske]

Hi Sven,


On 24 Apr 2020, at 11:08, Sven Van Caekenberghe wrote:

> Hi Max,
>
> Not an answer, but do you really need VNC to deploy on a server ?

It's certainly debatable. We're used to having it, that's the main reason.

>
> This is often unreliably and a bit overkill, it is also alien to the rest of 
> the server world.
>
> Provided you can build your project automatically from a single Metacello 
> invocation, you can build server side, command line as well.

We do have something similar and in most cases that's enough.

>
> I use a simple command line REPL for those harder problems that require 
> interacting with the image.
>
>   https://github.com/svenvc/NeoConsole
>
> You can type arbitrary expressions, look at code and even patch a method. 
> Yes, it is all primitive, but it can make a night and day difference if you 
> don't understand what is happening in real time.

Looks cool! I might give that a whirl. While our solution does work it has some 
rather annoying drawbacks. Actually, having a better way to interact via 
terminal would make VNC access even less important.

>
> I have never felt a need to use VNC for a full interactive IDE on a server.
>
> But maybe you have other reasons to go in that direction.
>
> Sven


Thanks for you thoughts.


Cheers,
Max

>
>> On 24 Apr 2020, at 10:51, Max Leske  wrote:
>>
>> Hi all,
>>
>> I'm trying to change the size of the display programmatically but am having 
>> some trouble. It used to be possible to do Display setExtent: 50@50 depth: 
>> 16 and that would take care of everything. I can still do that but 1. the 
>> renderer reverts the changes immediately and 2. if I prevent the renderer 
>> from reverting the changes the rendering is broken (which I can understand).
>>
>> So: how am I supposed to change the display size? Note: this is for the 
>> remote frame buffer in headless mode, so technically there's no OS window. 
>> Still the VM returns a fixed size of something close to 900x700.
>>
>> I can live with the fixed size if I have to but I'd rather be able to change 
>> the size (and also the bit depth as I don't need 32 bits for VNC).
>>
>> Cheers,
>> Max
>>


signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Programmatically change display size in Pharo 8 / 9

[Max Leske]

Hi all,

I'm trying to change the size of the display programmatically but am having 
some trouble. It used to be possible to do `Display setExtent: 50@50 depth: 16` 
and that would take care of everything. I can still do that but 1. the renderer 
reverts the changes immediately and 2. if I prevent the renderer from reverting 
the changes the rendering is broken (which I can understand).

So: how am I supposed to change the display size? Note: this is for the remote 
frame buffer in headless mode, so technically there's no OS window. Still the 
VM returns a fixed size of something close to 900x700.


I can live with the fixed size if I have to but I'd rather be able to change 
the size (and also the bit depth as I don't need 32 bits for VNC).


Cheers,
Max

signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Updated Fuel version for Pharo 8

[Max Leske]

Great! Will do.

On 8 Mar 2020, at 19:35, Esteban Lorenzano wrote:

> Ah, yes. Please do a PR :)
>
>> On 8 Mar 2020, at 19:28, Esteban Lorenzano  wrote:
>>
>> Hi Max,
>>
>> We will schedule a minor release with this and some other changes next 
>> week(s) :)
>>
>> Esteban
>>
>>
>>> On 8 Mar 2020, at 16:35, Max Leske  wrote:
>>>
>>> Hi folks,
>>>
>>> I just released Fuel 3.0.2 and I'd like to update the current version in 
>>> Pharo 8 to the new one. I know I'm past the Pharo 8 release date, so I 
>>> guess it won't happen but I thought I'd ask anyway.
>>>
>>> There are no functional changes in 3.0.2 but I've updated the platform 
>>> (it's currently still FLPharo7Platform in Pharo 8) and removed some unused 
>>> stuff. So should I open a PR?
>>>
>>>
>>> In any case I'll open a PR for Pharo 9.
>>>
>>> Cheers,
>>> Max
>>


signature.asc
Description: OpenPGP digital signature

[Pharo-dev] Updated Fuel version for Pharo 8

[Max Leske]

Hi folks,

I just released Fuel 3.0.2 and I'd like to update the current version in Pharo 
8 to the new one. I know I'm past the Pharo 8 release date, so I guess it won't 
happen but I thought I'd ask anyway.

There are no functional changes in 3.0.2 but I've updated the platform (it's 
currently still FLPharo7Platform in Pharo 8) and removed some unused stuff. So 
should I open a PR?


In any case I'll open a PR for Pharo 9.

Cheers,
Max

signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Doing the equivalent of "fast forward" with Iceberg

[Max Leske]

Hi Eliot,

First, save your image ;)

Then you should be able to fetch the changes from remote, if you haven't 
done so yet, and then *merge*. That should apply the changes without 
distroying your existing changes.
You'll also get a chance to review and select the changes that will be 
applied in the merge browser.


Disclaimer: I use Pharo 8 so I'm not 100% sure that all that 
functionality existst / works. I'm pretty confident though.



Cheers,
Max

On 17 Oct 2019, at 19:52, Eliot Miranda wrote:


Hi All,

I'm involved in a team project using Pharo 7.1.  I have some
uncommitted changes in a package that others have committed to.  I 
want to
pull their latest commits without overwriting mine and because my 
changes
are incomplete I don't yet want to commit, and hence don't want to 
create a

branch.

Can I just pull in the Pull tool without overwriting my changes?

Does this do the equivalent of git's "fast forward" if there are no
conflicts?

If there are conflicts, what happens?
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Fuel Not Serializing Stateful Traits

[Max Leske]

Hi,

As I wrote to Sean on Discord, Marcus fixed that bug during ESUG. I 
realize now, however, that it is only fixed in Pharo 8. I would need to 
write a patch for Fuel to make it work in Pharo 7.


Alternatively, you could include the patch in your code, then Fuel 
should work.



Cheers,
Max


On 24 Sep 2019, at 7:59, Alistair Grant wrote:


Hi Sean,


On Mon, 23 Sep 2019 at 23:37, Sean P. DeNigris  
wrote:


Sean P. DeNigris wrote

I see commit 1dd... back in March 2018 says it should work


Investigating a bit further, maybe the problem is in Pharo, because 
another
test in Pharo 8 didn't show the issue. instanceVariableNamesDo: 
doesn't seem
to have changed, so I guess it's deeper. Any ideas? Otherwise I'll 
have to

rollback my stateful trait usage until Pharo 8!


This might provide a bit more info:
https://github.com/pharo-project/pharo/issues/3546

Cheers,
Alistair

Re: [Pharo-dev] Changes proposal on Pre debugger

[Max Leske]

On 10 Jul 2019, at 20:21, Cyril Ferlicot D. wrote:


Hi,

After talking with Steven (in copy) we agreed on possible improvements
around the pre debugger. I would like to share our vision and check if
the community agrees.


The community agrees! ;)



Context:

The pre debugger is the window opening when an exception is signalled
and not catched. This window currently has two views:
- On warnings it display a text explaining the encountered problem. 
You

can the proceed, abandon or debug. For example, this happens on
Deprecations.
- On other exceptions it display a short stack of the context in which
the error was raised. You can abandon, open a full debugger, ...

Before, both views were managed via the same UI class. Yesterday I
slitted this class.

Proposed change:

In our opinion, the pre debugger displaying a stack is useless. All 
the
options it proposes are in the full debugger within one click reach. 
The

only value we see for the pre debugger is about warnings.

Thus, we propose to remove the stack pre debugger and display directly
the full debugger for anything else than a warning. This will save
everyone one click each time we want to debug something. We would keep
the textual view for warnings.


Yes please.



In case we do this, I wonder if we should keep the setting "Open full
debugger". I think most users of this option are using it in order to
not see the stack pre debugger and not to skip warnings. So, do 
someone
have an opinion about keeping or removing this setting in case we 
remove

the stack pre debugger?


I agree, remove the setting.



Possible future changes:

In the future I would also like it if the opening of the pre (or full)
debugger would be delegated to the raised exception in order to allow
the introduction of different pre debuggers. But it's just an idea and
not the scope of this mail. :)


Maybe not to the exception itself but to an optional handler than can be 
installed in the exception?



Cheers,
Max



--
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-dev] Read-only image mode

[Max Leske]

Awesome! Thanks!

On 9 Jul 2019, at 14:28, Pavel Krivanek wrote:

> Hi,
>
> the current Pharo cannot deal very well in situations when you want to run
> multiple instances from one image file, especially on Windows, which
> complicates the setup of parallel applications.  It is not able to work
> reasonably on read-only file-systems too. That's why I did the next attempt
> to improve this functionality of the system.
>
> In summary:
> - the image can be executed with --readOnlyMode image argument
> - the basic system tries to survive such limitation. The changes file is in
> read-only mode and new sources are installed into compiled methods
> directly, Ombu does not save content, Playground does not save cache etc.
> - PharoDebug.log and placeholder files on Windows are not created
> - the limitation is only on image-level so it is easy to bypass it.
> - the presence of the old file streams makes everything uglier and messier
>
> We have an open PR for this issue:
> https://github.com/pharo-project/pharo/pull/3837
>
> Comments and reviews are welcome.
>
> -- Pavel

Re: [Pharo-dev] how implement isAbstract?

[Max Leske]

On 30 Mar 2019, at 21:05, Denis Kudriashov wrote:


We can also look into it from the other side. All these methods are
definitely a kind of code duplication.
I think what we need here is an explicit property for classes. It 
could be

even part of class definition.


I'm not sure whether that's the right thing to do but I definitely like 
where you're going.
BTW, class initialization via Monticello (class side #initialize) also 
doesn't use inheritance (although I've always considered that a bug). 
I.e., Monticello only evalutes #initialize on the class that installed 
the #initialize method and not on any subclass. Maybe a general 
mechanism for marking a class as abstract could also include a mechanism 
to "override" method lookup.


Just some thoughts.

Max


BTW do we plan new class definition in Pharo 8?

сб, 30 мар. 2019 г. в 18:35, Denis Kudriashov 
:



Hello.

We did recently several cleanups by marking abstract classes as 
abstract
using #isAbstract method 
(https://github.com/pharo-project/pharo/pull/3087

, https://github.com/pharo-ide/Calypso/pull/462) .

I would like to discuss here and decide what the right way to 
implement

this method.

The logic behind is to only return true when receiver is defining 
class of
this method. And it should be false for any subclasses (if they do 
not

implement own #isAbstract method).

There is old pattern for implementation to compare name of class:

MyAbstractClass class>>isAbstract
  ^self name == #MyAbstractClass


It is used in many places (mostly tests). And it was used in recent 
Pharo

PR (3087).

We have another pattern in other places which simply compare self 
with

class:

MyAbstractClass class>>isAbstract
  ^self == MyAbstractClass


And in Calypso I used "more simplified" version using equality:

MyAbstractClass class>>isAbstract
  ^self = MyAbstractClass

I think we would all agree that simplest version is last one. It does 
not

raise any question about why we compare name or why we use identity
comparison. So this is my choice in this discussion.

Please write arguments about your preferred implementation. And let's
choose single way at the end. There is an idea to add a command into
browser to make classes abstract. And this decision will be used as a
template.


Best regards,
Denis

Re: [Pharo-dev] how implement isAbstract?

[Max Leske]

On 30 Mar 2019, at 20:56, Denis Kudriashov wrote:

> Hi Max.
>
> сб, 30 мар. 2019 г. в 19:08, Max Leske :
>
>> Hi Denis,
>>
>> I'm not too happy with any of those. For my own applications I use the
>> following:
>>
>> isAbstract
>> ^ self subclasses notEmpty and: [
>> (self class localSelectors includes: #isReallyAbstract) not or: [
>> self isReallyAbstract ] ]
>>
>> isReallyAbstract
>> "Override this method in any class that has children but should
>> *not* be considered abstract (while the children may be)."
>> ^ true
>>
>> The reason, as stated in the method comment, is that in nearly all of my
>> cases a class with subclasses should be considered abstract. Now, I don't
>> want to go and implement #isAbstract on each of those classes but at the
>> same time I need an escape hatch *which is not inherited*.
>> That's why I work around method lookup by checking for the existence of
>> the method first.
>>
>> I don't like how I have to hack around the method lookup but this works
>> far better from me than the class equality / identity check.
>>
>> On 30 Mar 2019, at 19:35, Denis Kudriashov wrote:
>>
>> Hello.
>>
>> We did recently several cleanups by marking abstract classes as abstract
>> using #isAbstract method (https://github.com/pharo-project/pharo/pull/3087
>> ,
>> https://github.com/pharo-ide/Calypso/pull/462) .
>>
>> I would like to discuss here and decide what the right way to implement
>> this method.
>>
>> The logic behind is to only return true when receiver is defining class of
>> this method. And it should be false for any subclasses (if they do not
>> implement own #isAbstract method).
>>
>> There is old pattern for implementation to compare name of class:
>>
>> MyAbstractClass class>>isAbstract
>> ^self name == #MyAbstractClass
>>
>>
>> It is used in many places (mostly tests). And it was used in recent Pharo
>> PR (3087).
>>
>> We have another pattern in other places which simply compare self with
>> class:
>>
>> MyAbstractClass class>>isAbstract
>> ^self == MyAbstractClass
>>
>> Otherwise, this would be my preferred method:
>> 1. minimum number of byte codes
>>
> Why it is important?
> If it is about speed then I don't believe you :) because your approach is
> very far from being optimized and I guess you are ok with that.

I know, and you're right of course. It's just the way I feel about the code :)

>
>> 2. Simple for refactoring tools to update the binding
>> 3. no use of #name
>>
>> Cheers,
>> Max
>>
>> And in Calypso I used "more simplified" version using equality:
>>
>> MyAbstractClass class>>isAbstract
>> ^self = MyAbstractClass
>>
>> I think we would all agree that simplest version is last one. It does not
>> raise any question about why we compare name or why we use identity
>> comparison. So this is my choice in this discussion.
>>
>> Please write arguments about your preferred implementation. And let's
>> choose single way at the end. There is an idea to add a command into
>> browser to make classes abstract. And this decision will be used as a
>> template.
>>
>>
>> Best regards,
>> Denis
>>
>>

Re: [Pharo-dev] how implement isAbstract?

[Max Leske]

Hi Denis,

I'm not too happy with any of those. For my own applications I use the 
following:


isAbstract
^ self subclasses notEmpty and: [
(self class localSelectors includes: #isReallyAbstract) not or: 
[
self isReallyAbstract ] ]


isReallyAbstract
"Override this method in any class that has children but should
*not* be considered abstract (while the children may be)."
^ true

The reason, as stated in the method comment, is that in nearly all of my 
cases a class with subclasses should be considered abstract. Now, I 
don't want to go and implement #isAbstract on each of those classes but 
at the same time I need an escape hatch *which is not inherited*.
That's why I work around method lookup by checking for the existence of 
the method first.


I don't like how I have to hack around the method lookup but this works 
far better from me than the class equality / identity check.



On 30 Mar 2019, at 19:35, Denis Kudriashov wrote:


Hello.

We did recently several cleanups by marking abstract classes as 
abstract
using #isAbstract method 
(https://github.com/pharo-project/pharo/pull/3087,

https://github.com/pharo-ide/Calypso/pull/462) .

I would like to discuss here and decide what the right way to 
implement

this method.

The logic behind is to only return true when receiver is defining 
class of

this method. And it should be false for any subclasses (if they do not
implement own #isAbstract method).

There is old pattern for implementation to compare name of class:

MyAbstractClass class>>isAbstract
  ^self name == #MyAbstractClass


It is used in many places (mostly tests). And it was used in recent 
Pharo

PR (3087).

We have another pattern in other places which simply compare self with
class:

MyAbstractClass class>>isAbstract
  ^self == MyAbstractClass


Otherwise, this would be my preferred method:
1. minimum number of byte codes
2. Simple for refactoring tools to update the binding
3. no use of #name



Cheers,
Max




And in Calypso I used "more simplified" version using equality:

MyAbstractClass class>>isAbstract
  ^self = MyAbstractClass

I think we would all agree that simplest version is last one. It does 
not

raise any question about why we compare name or why we use identity
comparison. So this is my choice in this discussion.

Please write arguments about your preferred implementation. And let's
choose single way at the end. There is an idea to add a command into
browser to make classes abstract. And this decision will be used as a
template.


Best regards,
Denis

Re: [Pharo-dev] Questions about DebugSession>>isContextPostMortem:

[Max Leske]

On 21 Mar 2019, at 11:06, Thomas Dupriez wrote:

Hi Thomas,


Hello,

While looking at the DebugSession>>isContextPostMortem: method (code 
below), I got three questions:


1) There is a check for whether the suspendedContext (top context) of 
the process is nil. Does it even make sense for a process not to have 
any top context?


Yes, only suspended processes have a suspendedContext. Also, the process 
might have been terminated already.




2) It seems that all the last 3 lines are doing is to check whether 
selectedContext is in the context chain of the process. Could they be 
rewritten into this simpler one-liner?   `|^ (suspendedContext 
hasContext: selectedContext) not`|


Yes, I think that would work.



3) Overall, this method says that a context C is "post mortem" if the 
process controlled by the DebugSession has a top context and C is not 
in its context chain. That's the practical definition. Could someone 
shed some light on the high-level definition of "post mortem"? Because 
"post mortem" is like "after death", but the death of what? A context 
that merely belongs to another context chain would be considered "post 
mortem" by the practical definition, but there's no death in this 
case...

||



You can create a copy of a process' stack. That stack will behave like a 
process in the debugger but it can't run, as the VM doesn't have a 
process to which the context are attached, hence it's considered 
post-mortem.




```

|DebugSession>>isContextPostMortem: selectedContext "return whether 
we're inspecting a frozen exception without a process attached" | 
suspendedContext | suspendedContext := interruptedProcess 
suspendedContext. suspendedContext ifNil: [ ^ false ]. 
(suspendedContext == selectedContext) ifTrue: [ ^ false ]. ^ 
(suspendedContext findContextSuchThat: [:c | c sender == 
selectedContext]) isNil ``` |


Does someone know the answer to some (or all) of these questions?

Thomas



Hope that helps.

Max

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

[Max Leske]

On 19 Mar 2019, at 16:16, Gabriel Cotelli wrote:

If you don't clean up the instance variables, when you have a lot of 
tests
and a test runner is still open on the results all this garbage is 
still
referenced (because the test results keeps a reference to the original 
test
case instance) and the image keeps growing like crazy. I can tell you 
for
my experience that in our case it gets easily to GB-sized images, and 
the

GC is not very happy with this.


Indeed.



On Tue, Mar 19, 2019 at 12:04 PM Attila Magyar  
wrote:



Max Leske wrote
To answer your question: yes that has been the case for a long time. 
The
same is true for #runCase BTW. Only #setUp is sent after #tearDown 
(see

#prepareToRunAgain).

Max


That's weird. RunCase sends a setUp, a tearDown and
cleanUpInstanceVariables. So the test will be executed with 
uninitialized

instance variables at the second time. Why do we need to clean up the
instance variables? Or why don't we reinitialize them before running 
the

test?


I understand your grief. My solution: never use #initalize in tests, use 
#setUp to initialize instance variables.


Max





--
Sent from: 
http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

[Max Leske]

To answer your question: yes that has been the case for a long time. The 
same is true for #runCase BTW. Only #setUp is sent after #tearDown (see 
#prepareToRunAgain).


Max

On 18 Mar 2019, at 14:05, Attila Magyar wrote:


Thanks, I added the ticket.



--
Sent from: 
http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] OSProcess for Pharo 7

[Max Leske]

On 14 Mar 2019, at 20:00, ducasse wrote:


I was talking about OSSubProcess


Well, I'm not working with that at the moment ;)




On 14 Mar 2019, at 18:21, Tim Mackinnon  wrote:

I’ve been using OSProcess on OSX for exercism (development mode) 
and its been working fine. (I’ve been piping a go executable output 
to run a generation command)



On 14 Mar 2019, at 16:38, ducasse  wrote:




On 14 Mar 2019, at 17:33, Max Leske  wrote:

On 13 Mar 2019, at 11:55, ducasse wrote:

Ok now one of these days we will have to have all the important 
libraries hosted in the same place.

It is not sure that we will maintain MC forever.
For example SmalltalkHub should get readonly by the end of the 
year (for lack of maintenance reason).

BTW is OSSubProcess working for you?


Yes, it works. There appear to be some methods that need to be 
updated but general functionality is there.


Let us know because Guille did a pass on Mariano’s version and we 
are ready to improve it.




Max




Hi Stef,

On 11 Mar 2019, at 8:12, ducasse wrote:


Max

ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit 
normal that it got removed in P7. But we should check this.

I do not have the time today for this.

normally ifNotNilDo: should be covered by a migrator automatic 
rewrite rules (can you check?): Ducasse/Migrator
because in such case you load the migrator packages and execute 
the tests of the OSProcess (if any)
then you execute OSProcess and the user of ifNotNilDo: will be 
automatically rewritten and you are just left to check

the senders that are left and commit a new version.


You have extensions defined for #ifNotNilDo: in your migration 
definition for 50 to 60.




If IfNotNilDo: is not covered by a automated migration we should 
add one.
It was deprecated before the automated migrations were 
introduced.



Now about your question: yes a new version of OSProcess should 
be produced for P7.

The best would be to migrate it to github.


I think Dave might disagree ;) If the maintainers are fine with 
moving to Github then that would be great. I assume that there 
will be some objections to that (e.g. because of loading in 
Squeak?) and we (I at least) don't want to maintain a fork / 
mirror on Github.

Pulling from SqueakSource works fine for now.

Max



Let me know if it helps.

Stef


On 11 Mar 2019, at 08:00, Max Leske  wrote:

Hi all,

Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess 
loading fails. I volunteer to update OSProcess for Pharo 7 but 
I need someone to tell me what the expected workflow is. 
AFAICT, we've simply copied the current ConfigurationOf to the 
MetaRepoForXX in the past without making any changes specific 
to Pharo. That will not work this time.
So, should I create a new version of OSProcess for all 
platforms, where #ifNotNilDo: has been replaced with 
#ifNotNil:? Or should I add a compatibility package for Pharo? 
Or something else?


Cheers,
Max

Re: [Pharo-dev] OSProcess for Pharo 7

[Max Leske]

On 13 Mar 2019, at 11:55, ducasse wrote:

Ok now one of these days we will have to have all the important 
libraries hosted in the same place.

It is not sure that we will maintain MC forever.
For example SmalltalkHub should get readonly by the end of the year 
(for lack of maintenance reason).

BTW is OSSubProcess working for you?


Yes, it works. There appear to be some methods that need to be updated 
but general functionality is there.


Max




Hi Stef,

On 11 Mar 2019, at 8:12, ducasse wrote:


Max

ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit 
normal that it got removed in P7. But we should check this.

I do not have the time today for this.

normally ifNotNilDo: should be covered by a migrator automatic 
rewrite rules (can you check?): Ducasse/Migrator
because in such case you load the migrator packages and execute the 
tests of the OSProcess (if any)
then you execute OSProcess and the user of ifNotNilDo: will be 
automatically rewritten and you are just left to check

the senders that are left and commit a new version.


You have extensions defined for #ifNotNilDo: in your migration 
definition for 50 to 60.




If IfNotNilDo: is not covered by a automated migration we should add 
one.

It was deprecated before the automated migrations were introduced.


Now about your question: yes a new version of OSProcess should be 
produced for P7.

The best would be to migrate it to github.


I think Dave might disagree ;) If the maintainers are fine with 
moving to Github then that would be great. I assume that there will 
be some objections to that (e.g. because of loading in Squeak?) and 
we (I at least) don't want to maintain a fork / mirror on Github.

Pulling from SqueakSource works fine for now.

Max



Let me know if it helps.

Stef


On 11 Mar 2019, at 08:00, Max Leske  wrote:

Hi all,

Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess 
loading fails. I volunteer to update OSProcess for Pharo 7 but I 
need someone to tell me what the expected workflow is. AFAICT, 
we've simply copied the current ConfigurationOf to the 
MetaRepoForXX in the past without making any changes specific to 
Pharo. That will not work this time.
So, should I create a new version of OSProcess for all platforms, 
where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I 
add a compatibility package for Pharo? Or something else?


Cheers,
Max

Re: [Pharo-dev] OSProcess for Pharo 7

[Max Leske]

On 13 Mar 2019, at 11:55, ducasse wrote:

Ok now one of these days we will have to have all the important 
libraries hosted in the same place.

It is not sure that we will maintain MC forever.
For example SmalltalkHub should get readonly by the end of the year 
(for lack of maintenance reason).

BTW is OSSubProcess working for you?


So far I've only loaded it. I'll let yo know when I've run some tests.




Hi Stef,

On 11 Mar 2019, at 8:12, ducasse wrote:


Max

ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit 
normal that it got removed in P7. But we should check this.

I do not have the time today for this.

normally ifNotNilDo: should be covered by a migrator automatic 
rewrite rules (can you check?): Ducasse/Migrator
because in such case you load the migrator packages and execute the 
tests of the OSProcess (if any)
then you execute OSProcess and the user of ifNotNilDo: will be 
automatically rewritten and you are just left to check

the senders that are left and commit a new version.


You have extensions defined for #ifNotNilDo: in your migration 
definition for 50 to 60.




If IfNotNilDo: is not covered by a automated migration we should add 
one.

It was deprecated before the automated migrations were introduced.


Now about your question: yes a new version of OSProcess should be 
produced for P7.

The best would be to migrate it to github.


I think Dave might disagree ;) If the maintainers are fine with 
moving to Github then that would be great. I assume that there will 
be some objections to that (e.g. because of loading in Squeak?) and 
we (I at least) don't want to maintain a fork / mirror on Github.

Pulling from SqueakSource works fine for now.

Max



Let me know if it helps.

Stef


On 11 Mar 2019, at 08:00, Max Leske  wrote:

Hi all,

Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess 
loading fails. I volunteer to update OSProcess for Pharo 7 but I 
need someone to tell me what the expected workflow is. AFAICT, 
we've simply copied the current ConfigurationOf to the 
MetaRepoForXX in the past without making any changes specific to 
Pharo. That will not work this time.
So, should I create a new version of OSProcess for all platforms, 
where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I 
add a compatibility package for Pharo? Or something else?


Cheers,
Max

Re: [Pharo-dev] OSProcess for Pharo 7

[Max Leske]

Hi Stef,

On 11 Mar 2019, at 8:12, ducasse wrote:


Max

ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit 
normal that it got removed in P7. But we should check this.

I do not have the time today for this.

normally ifNotNilDo: should be covered by a migrator automatic rewrite 
rules (can you check?): Ducasse/Migrator
because in such case you load the migrator packages and execute the 
tests of the OSProcess (if any)
then you execute OSProcess and the user of ifNotNilDo: will be 
automatically rewritten and you are just left to check

the senders that are left and commit a new version.


You have extensions defined for #ifNotNilDo: in your migration 
definition for 50 to 60.




If IfNotNilDo: is not covered by a automated migration we should add 
one.

It was deprecated before the automated migrations were introduced.


Now about your question: yes a new version of OSProcess should be 
produced for P7.

The best would be to migrate it to github.


I think Dave might disagree ;) If the maintainers are fine with moving 
to Github then that would be great. I assume that there will be some 
objections to that (e.g. because of loading in Squeak?) and we (I at 
least) don't want to maintain a fork / mirror on Github.

Pulling from SqueakSource works fine for now.

Max



Let me know if it helps.

Stef


On 11 Mar 2019, at 08:00, Max Leske  wrote:

Hi all,

Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess 
loading fails. I volunteer to update OSProcess for Pharo 7 but I need 
someone to tell me what the expected workflow is. AFAICT, we've 
simply copied the current ConfigurationOf to the MetaRepoForXX in the 
past without making any changes specific to Pharo. That will not work 
this time.
So, should I create a new version of OSProcess for all platforms, 
where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add 
a compatibility package for Pharo? Or something else?


Cheers,
Max

Re: [Pharo-dev] #currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open

[Max Leske]

On 8 Mar 2019, at 8:33, Alistair Grant wrote:


Hi Max,

On Fri, 8 Mar 2019 at 08:21, Max Leske  wrote:


Hi,

OSPlatform>>currentWorkingDirectoryPath (used by 
Path>>workingDirectory,
used by Metacello to resolve local paths) always answers '/' for me 
when

I drag the image onto the VM to open. I'm sure that's a "feature" of
macOS but it's very annoying.
In addition, FileLocator imageDirectory answers the correct
workingDirectory because it uses a primitive instead of the FFI call 
to

getCwd().

Is this a known issue? Should I open a new one?


This is known behaviour.  #imageDirectory and #workingDirectory are
distinct concepts.  #imageDirectory, obviously, is the location where
the image resides, while #workingDirectory is the current working
directory for the process.

It's unfortunate that MacOS sets cwd to "/" when starting applications
through the GUI.  It sounds like you are already aware of this, but
just to be clear: if you start Pharo from a shell you should see
#workingDirectory return the same value as `pwd` in the shell.

I'm not a Mac user, so I don't know what other applications typically
do, but maybe wrap the startup in a script that changes to something
more sensible (in your case above it sounds like changing to the
directory where the image is located).  But modifying
#workingDirectory to answer the image directory isn't a good idea as
it breaks lots of other use cases.

Cheers,
Alistair



Thanks Alistair. I suspected as much. In my case the solution will be to 
compose the path to the repository in the baseline by hand before 
passing it to Metacello (e.g. `repository: 'filetree:', (FileLocator 
imageDirectory) pathString, '...'`.


Cheers,
Max

[Pharo-dev] #currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open

[Max Leske]

Hi,

OSPlatform>>currentWorkingDirectoryPath (used by Path>>workingDirectory, 
used by Metacello to resolve local paths) always answers '/' for me when 
I drag the image onto the VM to open. I'm sure that's a "feature" of 
macOS but it's very annoying.
In addition, FileLocator imageDirectory answers the correct 
workingDirectory because it uses a primitive instead of the FFI call to 
getCwd().


Is this a known issue? Should I open a new one?

Max

Re: [Pharo-dev] Apparently Zodiac plugin can crash VM on Linux

[Max Leske]

I've heard from Martin again:

embee
i think i figured out the problem: ZnClient works with libssl 1.0.0 but 
not with 1.1. if i force a symlink from 1.1 to 1.0.0 then ZnClient 
works, however git still fails because it links against libldap which 
links against openssl 1.1.
it looks like the way to fix this would be to make ZnClient work with 
openssl 1.1



Max


On 16 Jan 2019, at 16:37, Sven Van Caekenberghe wrote:


On 16 Jan 2019, at 16:28, Max Leske  wrote:

On 15 Jan 2019, at 22:59, Sven Van Caekenberghe wrote:

Doing HTTPS client calls is part of the standard test suite, so it 
should work, else we would not have a green build.


It works for me and for the CI.


What exactly is he doing ? Is it reproducible ?

Yes, consistently.


How ?


Can he try with a fresh downloaded image+vm ?

I quote:

@embee
i have tested 
https://files.pharo.org/get-files/70/pharo64-linux-stable.zip and 
https://files.pharo.org/get-files/70/pharo64-linux-latest.zip

i hope those are the right ones. both crash

@maxleske
Thanks. I'll report that.
Was that also with a fresh image?
i.e. you can also reprocude it with a fresh image, right?

@embee
yes

On 15 Jan 2019, at 22:20, Max Leske maxle...@gmail.com wrote:

Hi,

I'm writing on behalf of Martin (eMBee) who's experiencing crashes 
when using SSL. You can find a VM crash stack trace here: 
http://ws.stfx.eu/AKVNLUPMPGLG.


He says he hasn't updated openssl since December 15th but that the 
crashes started to happen only recently (within the last couple of 
days). I asked him to try HTTP only connections and those work. The 
VM crashes immediately when using SSL. To me it looks like the 
cuplrit is the Zodiac plugin, or at least the library it works with.


His system:
linux, fedora 29, and from the system reporter i get: 
Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo
CoInterpreter VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
VM: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 
28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git


cheers,
Max

Re: [Pharo-dev] [Glass] Bug in Regex?

[Max Leske]

On 21 Feb 2019, at 16:25, Mariano Martinez Peck wrote:

> Hi Max,
>
> I opened this case [1] with the explanation and the fix. If you can give it
> a try, that would be great. I would also like to improve the test I wrote,
> so if you have more edge cases or ideas I can assert, let me know.

Great. I'll take a look when I get a chance.

>
> [1] https://github.com/pharo-project/pharo/issues/2679
>
> Cheers,
>
>
> On Thu, Feb 21, 2019 at 10:44 AM Max Leske  wrote:
>
>> On 21 Feb 2019, at 13:40, Mariano Martinez Peck wrote:
>>
>>> Vassili Bykov Hi Max,
>>>
>>> It looks like it was fixed on a later version of VBRegex. I was able
>>> to
>>> extract the 2 little changes to make it work. Do you know if there is
>>> an
>>> issue already open for this so that I can submit the changes?
>>>
>>> BTW, I am trying to understand the history of Regex. It's clear that
>>> the
>>> original implementation was done by Vassili Bykov and the packages
>>> were
>>> called VBRegex and that was in VW under the Public Store. I guess, at
>>> some
>>> point, that code was ported to Pharo. In Pharo 1.1 the packages are
>>> still
>>> called 'VB-Regex' but on recent ones its called "Regex".
>>>
>>
>> The package name changed between Pharo 1.1.2 and Pharo 1.2.2, as far as
>> I can tell from the images I have on my machine.
>>
>>> What I cannot confirm is which version Pharo (or maybe this was even
>>> en
>>> Squeak before Pharo forked) ported from VW.  All I could find is a
>>> class
>>> comment on RxMatcher saying "-- Regular Expression Matcher v 1.1 (C)
>>> 1996,
>>> 1999 Vassili Bykov". As  you can see, that is 1999. VW has newer
>>> versions
>>> from 1.2.x to 1.4.x, latest commit being on 2014.
>>
>> The oldest images I have is Squeak3.9 of 7 November 2006 update 7067,
>> and that already contains VBRegex.
>>
>>>
>>> The particular problem we are discussing in this thread was fixed in
>>> 1.3.1.
>>>
>>> So I am not sure if someone ever tried porting again a newer version
>>> to
>>> Pharo? It doesn't seem the case.
>>
>> It would certainly be great to get those fixes!
>>
>>>
>>> Anyone knows a bit more the history here?
>>>
>>> Thanks
>>>
>>>
>>> On Thu, Feb 21, 2019 at 5:18 AM Max Leske  wrote:
>>>
>>>> Hi Mariano,
>>>>
>>>> Yes, there is indeed such a bug (if it hasn't been fixed in an update
>>>> to
>>>> VBRegex that is). The bug is simple to work around though, as all you
>>>> have
>>>> to do is sort your branch (|) terms by length. Here's the comment
>>>> I've
>>>> written for a regex generating method is use:
>>>>
>>>> " The sorting is very important because VB-Regex aborts early on
>>>> branches.
>>>> Example: 'bl' matchesRegex: 'b|bl' --> false The solution is to sort
>>>> by
>>>> length (longest first), then alphabetically, with the short group
>>>> optimization at the end. "
>>>>
>>>> Cheers,
>>>> Max
>>>>
>>>> On 21 Feb 2019, at 3:33, Mariano Martinez Peck wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Feb 20, 2019 at 5:56 PM Esteban Maringolo via Glass <
>>>> gl...@lists.gemtalksystems.com> wrote:
>>>>
>>>>> What a good case to have GToolkit visualizations help debugging this
>>>>> RX
>>>>> tree ;)
>>>>>
>>>>>
>>>> Oh yeah..And look Doru, they have some stuff on the top right
>>>> "Explanation" panel: https://regex101.com/r/MqVXz8/1
>>>>
>>>>
>>>> --
>>>> Mariano
>>>> https://twitter.com/MartinezPeck
>>>> http://marianopeck.wordpress.com
>>>>
>>>>
>>>
>>> --
>>> Mariano
>>> https://twitter.com/MartinezPeck
>>> http://marianopeck.wordpress.com
>>
>>
>>
>>
>
> -- 
> Mariano
> https://twitter.com/MartinezPeck
> http://marianopeck.wordpress.com

Re: [Pharo-dev] [Glass] Bug in Regex?

[Max Leske]

On 21 Feb 2019, at 13:40, Mariano Martinez Peck wrote:


Vassili Bykov Hi Max,

It looks like it was fixed on a later version of VBRegex. I was able 
to
extract the 2 little changes to make it work. Do you know if there is 
an

issue already open for this so that I can submit the changes?

BTW, I am trying to understand the history of Regex. It's clear that 
the
original implementation was done by Vassili Bykov and the packages 
were
called VBRegex and that was in VW under the Public Store. I guess, at 
some
point, that code was ported to Pharo. In Pharo 1.1 the packages are 
still

called 'VB-Regex' but on recent ones its called "Regex".



The package name changed between Pharo 1.1.2 and Pharo 1.2.2, as far as 
I can tell from the images I have on my machine.


What I cannot confirm is which version Pharo (or maybe this was even 
en
Squeak before Pharo forked) ported from VW.  All I could find is a 
class
comment on RxMatcher saying "-- Regular Expression Matcher v 1.1 (C) 
1996,
1999 Vassili Bykov". As  you can see, that is 1999. VW has newer 
versions

from 1.2.x to 1.4.x, latest commit being on 2014.


The oldest images I have is Squeak3.9 of 7 November 2006 update 7067, 
and that already contains VBRegex.




The particular problem we are discussing in this thread was fixed in
1.3.1.

So I am not sure if someone ever tried porting again a newer version 
to

Pharo? It doesn't seem the case.


It would certainly be great to get those fixes!



Anyone knows a bit more the history here?

Thanks


On Thu, Feb 21, 2019 at 5:18 AM Max Leske  wrote:


Hi Mariano,

Yes, there is indeed such a bug (if it hasn't been fixed in an update 
to
VBRegex that is). The bug is simple to work around though, as all you 
have
to do is sort your branch (|) terms by length. Here's the comment 
I've

written for a regex generating method is use:

" The sorting is very important because VB-Regex aborts early on 
branches.
Example: 'bl' matchesRegex: 'b|bl' --> false The solution is to sort 
by

length (longest first), then alphabetically, with the short group
optimization at the end. "

Cheers,
Max

On 21 Feb 2019, at 3:33, Mariano Martinez Peck wrote:



On Wed, Feb 20, 2019 at 5:56 PM Esteban Maringolo via Glass <
gl...@lists.gemtalksystems.com> wrote:

What a good case to have GToolkit visualizations help debugging this 
RX

tree ;)



Oh yeah..And look Doru, they have some stuff on the top right
"Explanation" panel: https://regex101.com/r/MqVXz8/1


--
Mariano
https://twitter.com/MartinezPeck
http://marianopeck.wordpress.com




--
Mariano
https://twitter.com/MartinezPeck
http://marianopeck.wordpress.com

Re: [Pharo-dev] [Glass] Bug in Regex?

[Max Leske]

Hi Mariano,

Yes, there is indeed such a bug (if it hasn't been fixed in an update to 
VBRegex that is). The bug is simple to work around though, as all you 
have to do is sort your branch (|) terms by length. Here's the comment 
I've written for a regex generating method is use:


" The sorting is very important because VB-Regex aborts early on 
branches. Example:

'bl' matchesRegex: 'b|bl' --> false
	The solution is to sort by length (longest first), then alphabetically, 
with the short group optimization at the end. "



Cheers,
Max


On 21 Feb 2019, at 3:33, Mariano Martinez Peck wrote:


On Wed, Feb 20, 2019 at 5:56 PM Esteban Maringolo via Glass <
gl...@lists.gemtalksystems.com> wrote:

What a good case to have GToolkit visualizations help debugging this 
RX

tree ;)


Oh yeah..And look Doru, they have some stuff on the top right 
"Explanation"

panel: https://regex101.com/r/MqVXz8/1


--
Mariano
https://twitter.com/MartinezPeck
http://marianopeck.wordpress.com

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

[Max Leske]

Yeah. I hadn't realized that you were launching Iceberg *within* 
launcher. I launched an image first and then opened Iceberg in there.


Max

On 14 Feb 2019, at 23:26, Christophe Demarey wrote:

Le 14 févr. 2019 à 22:34, Sean P. DeNigris  
a écrit :


demarey wrote
Probably because the email title is « can’t install launcher … 
» and the

issue only raises if you try to open Iceberg ;)


Except Max said:
I downloaded it again... and opened Iceberg without issues.
!!


Good catch. I should have read more carefully!
Indeed, strange that Max did not get the issue.

Could it be that Max tried to open it in a launched image?

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

[Max Leske]

I downloaded it again, extracted it to /Applications, ran Pharo7-64bit 
and opened Iceberg without issues. Launcher created the working 
directory at ~/Documents/Pharo, which should be fine w.r.t. permissions.


I'm out of ideas...

On 13 Feb 2019, at 19:23, Sean P. DeNigris wrote:


Max Leske wrote
Nope. I downloaded launcher just 20 minutes ago on Mojave and am 
using

it without problems.


Weird. Nuked startup preferences folder just in case. fullPath 
modification

didn't help.


Where did you extract it to?

~/Application


Did you extract it as a different user?

Doesn't look like it


Did you try to run it from within the .dmg directly?

No. Opened the dmg, dragged it into apps folder, then opened that



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

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

[Max Leske]

Nope. I downloaded launcher just 20 minutes ago on Mojave and am using 
it without problems. Where did you extract it to? Did you extract it as 
a different user? Did you try to run it from within the .dmg directly?



Max

On 13 Feb 2019, at 3:42, Sean P. DeNigris wrote:


Just dl-ed launcher from Pharo.org. Attempting to open Iceberg gives:
"NotFound: Could not find repository from '/'". Seems to be coming 
from

libgit. Anyone else seeing this?



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

Re: [Pharo-dev] Apparently Zodiac plugin can crash VM on Linux

[Max Leske]

On 15 Jan 2019, at 22:59, Sven Van Caekenberghe wrote:

Doing HTTPS client calls is part of the standard test suite, so it 
should work, else we would not have a green build.


What exactly is he doing ? Is it reproducible ?


Yes, consistently.



Can he try with a fresh downloaded image+vm ?


I quote:

@embee
	i have tested 
https://files.pharo.org/get-files/70/pharo64-linux-stable.zip and 
https://files.pharo.org/get-files/70/pharo64-linux-latest.zip

i hope those are the right ones. both crash

@maxleske
Thanks. I'll report that.
Was that also with a fresh image?
i.e. you can also reprocude it with a fresh image, right?

@embee
yes




On 15 Jan 2019, at 22:20, Max Leske  wrote:

Hi,

I'm writing on behalf of Martin (eMBee) who's experiencing crashes 
when using SSL. You can find a VM crash stack trace here: 
http://ws.stfx.eu/AKVNLUPMPGLG.


He says he hasn't updated openssl since December 15th but that the 
crashes started to happen only recently (within the last couple of 
days). I asked him to try HTTP only connections and those work. The 
VM crashes immediately when using SSL. To me it looks like the 
cuplrit is the Zodiac plugin, or at least the library it works with.


His system:
linux, fedora 29, and from the system reporter i get: 
Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo
CoInterpreter VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
VM: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 
28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git


cheers,
Max

Re: [Pharo-dev] A problem with latest image (64bit) ? (Please confirm)

[Max Leske]

Actually, I think it's rather a VM problem...?


On 15 Jan 2019, at 12:30, Esteban Lorenzano wrote:


Hello,

I’m experiencing a problem with latest image (and latest vm) in Mac 
(Mojave).

After doing

Stdio stdout << ‘OK’

I’m having this stack:

File class(ProtoObject)>>primitiveFailed:
File class(ProtoObject)>>primitiveFailed
File class>>fileDescriptorType:
File class>>fileDescriptorIsAvailable:
Stdio class>>standardIOStreamNamed:forWrite:
Stdio class>>stdout
UndefinedObject>>DoIt
OpalCompiler>>evaluate
RubSmalltalkEditor>>evaluate:andDo:
RubSmalltalkEditor>>highlightEvaluateAndDo:
GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>popupPrint
MorphicAlarm(MessageSend)>>value
MorphicAlarm>>value:
WorldState>>triggerAlarmsBefore:
WorldState>>runLocalStepMethodsIn:
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
WorldMorph class>>doOneCycle
[ [ WorldMorph doOneCycle.
Processor yield.
false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess in 
Block: [ [ WorldMorph doOneCycle

[ self value.
Processor terminateActive ] in BlockClosure>>newProcess in Block: [ 
self value


Con someone confirm or refute this?

Thanks!
Esteban

Re: [Pharo-dev] A problem with latest image (64bit) ? (Please confirm)

[Max Leske]

I've been seeing this in the early Pharo 7 builds. But it didn't occur 
with latest VM's, only with SmalltalkCI, so I ignored it.


On 15 Jan 2019, at 12:30, Esteban Lorenzano wrote:


Hello,

I’m experiencing a problem with latest image (and latest vm) in Mac 
(Mojave).

After doing

Stdio stdout << ‘OK’

I’m having this stack:

File class(ProtoObject)>>primitiveFailed:
File class(ProtoObject)>>primitiveFailed
File class>>fileDescriptorType:
File class>>fileDescriptorIsAvailable:
Stdio class>>standardIOStreamNamed:forWrite:
Stdio class>>stdout
UndefinedObject>>DoIt
OpalCompiler>>evaluate
RubSmalltalkEditor>>evaluate:andDo:
RubSmalltalkEditor>>highlightEvaluateAndDo:
GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>popupPrint
MorphicAlarm(MessageSend)>>value
MorphicAlarm>>value:
WorldState>>triggerAlarmsBefore:
WorldState>>runLocalStepMethodsIn:
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
WorldMorph class>>doOneCycle
[ [ WorldMorph doOneCycle.
Processor yield.
false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess in 
Block: [ [ WorldMorph doOneCycle

[ self value.
Processor terminateActive ] in BlockClosure>>newProcess in Block: [ 
self value


Con someone confirm or refute this?

Thanks!
Esteban

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

On 22 Jul 2018, at 12:10, Norbert Hartl wrote:

Thank you guys! It is really great to see that there are people like 
Max jumping onto problems like this and solving it.


You're welcome!



@sven I’m eager to test when the new configuration is available. 
Please drop us a note when you are done!


thanks again,

Norbert


Am 22.07.2018 um 11:06 schrieb Sven Van Caekenberghe :

Ah, that makes total sense. Great catch. Thank you.

===
Name: Zinc-FileSystem-SvenVanCaekenberghe.17
Author: SvenVanCaekenberghe
Time: 22 July 2018, 11:04:40.148339 am
UUID: e97a508e-f42d-0d00-a127-f016078b1897
Ancestors: Zinc-FileSystem-SvenVanCaekenberghe.16

Bugfix to ZnFileSystemUtils class>>#newBinaryFileNamed:do: we must 
ensure that the binaryStream opened here is closed as well (thx Max 
Leske for the bug hunting and fix)

===

The method in question now look as follows:

newBinaryFileNamed: fileName do: block
| fileReference |
fileReference := fileName asFileReference.
^ (fileReference respondsTo: #binaryWriteStreamDo:ifPresent:)
ifTrue: [
fileName asFileReference
binaryWriteStreamDo: block
ifPresent: [ FileExists signalWith: 
fileReference ] ]
ifFalse: [
fileReference isFile
ifTrue: [ FileExists signalWith: fileReference ]
ifFalse: [ | binaryStream |
binaryStream := self 
binaryFileStreamFor: fileName.
[ block value: binaryStream ] ensure: [ 
binaryStream close ] ] ]

I create a new 2.9.4 of the config later on.


On 21 Jul 2018, at 22:00, Max Leske  wrote:

Sven, you're right. What I found last time works as a side-effect. 
The real problem is in ZnFileSystemUtils 
class>>newBinaryFileNamed:do:. In Pharo 6.1 the logic there leads to 
the following evaluation:


block value: (self binaryFileStreamFor: fileName)

This is the only place where the stream is created without a 
surrounding safety block (e.g. #writeStream:do:), which means, no 
one closes the stream. The line should be:


| s |
s := self binaryFileStreamFor: fileName.
[ block value: s ] ensure: [ s close ]

ZnFileSystemUtils class>>newBinaryFileNamed:do: is only used by 
ZnClient after loading Zinc-HTTP-SvenVanCaekenberghe.472, which is 
being loaded by version 2.9.1 of ConfigurationOfZincHTTPComponents.


Cheers,
Max

On 21 Jul 2018, at 17:21, Max Leske wrote:

Just to be safe, I'll redo my experiment and get back to you.

On 21 Jul 2018, at 16:59, Sven Van Caekenberghe wrote:
I tried running Max's snippet (Pharo 6.1 on Ubuntu 16.04 LTS),

ZnClient new
url: 'https://github.com/zweidenker/Parasol/archive/master.zip';
downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s 
| s contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference 
binaryReadStreamDo: [ :s | s contents ]) size.


And it gives me,

318420
318420

For me there is nothing nothing to see here ... and I have the 
impression we are all talking about different things.

On 21 Jul 2018, at 14:18, Max Leske  wrote:

On 21 Jul 2018, at 12:07, Norbert Hartl wrote:
Max,

what do you think will be a proper fix for this? I cannot see if 
this is a vm problem or not.


In my opinion it should be fixed in Zinc as there's no way for the 
user of Zinc to flush the stream. The alternative would be for Zinc 
to expose a method or setting that allows the user to specify the 
expected behaviour.
I do not think that this should be handled by the VM plugin or the 
stream class, as there are indeed different behaviours that make 
sense.


Cheers,
Max
Norbert
Am 14.07.2018 um 08:25 schrieb Max Leske :

Hi Nicolas,

The PR you are referring [1] to concerns a missing fflush() when 
truncating a file. I believe that is a different case to this one, 
as a) the file is not truncated and b) in the case of truncation it 
is an explicit requirement that the file be empty before the first 
write happens. In our case, and in general, it depends on the 
situation whether flushing must occur immediately, e.g. because the 
file will be read again immediately, or not, e.g. when writing a 
data to a backup file.


Thanks for the pointer though.


Cheers,
Max


[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271
On 12 Jul 2018, at 23:19, Nicolas Cellier wrote:

Isn't there a recent PR on opensmalltalk that address just this?
Le jeu. 12 juil. 2018 à 23:16, Max Leske  a 
écrit :


Hi Norbert,

I was able to reproduce the problem and then identify the culprit,
although what I don't yet understand is how this is related to the 
changes

in Zinc.

Anyway, the problem is that the file stream isn't properly flushed 
in
ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as th

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

Sven, you're right. What I found last time works as a side-effect. The 
real problem is in ZnFileSystemUtils class>>newBinaryFileNamed:do:. In 
Pharo 6.1 the logic there leads to the following evaluation:


`block value: (self binaryFileStreamFor: fileName)`

This is the only place where the stream is created without a surrounding 
safety block (e.g. #writeStream:do:), which means, no one closes the 
stream. The line should be:


`| s |
s := self binaryFileStreamFor: fileName.
[ block value: s ] ensure: [ s close ]`

ZnFileSystemUtils class>>newBinaryFileNamed:do: is only used by ZnClient 
after loading Zinc-HTTP-SvenVanCaekenberghe.472, which is being loaded 
by version 2.9.1 of ConfigurationOfZincHTTPComponents.



Cheers,
Max



On 21 Jul 2018, at 17:21, Max Leske wrote:


Just to be safe, I'll redo my experiment and get back to you.

On 21 Jul 2018, at 16:59, Sven Van Caekenberghe wrote:


I tried running Max's snippet (Pharo 6.1 on Ubuntu 16.04 LTS),

ZnClient new
url: 'https://github.com/zweidenker/Parasol/archive/master.zip';
downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | 
s contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference 
binaryReadStreamDo: [ :s | s contents ]) size.


And it gives me,

318420
318420

For me there is nothing nothing to see here ... and I have the 
impression we are all talking about different things.



On 21 Jul 2018, at 14:18, Max Leske  wrote:

On 21 Jul 2018, at 12:07, Norbert Hartl wrote:


Max,

what do you think will be a proper fix for this? I cannot see if 
this is a vm problem or not.


In my opinion it should be fixed in Zinc as there's no way for the 
user of Zinc to flush the stream. The alternative would be for Zinc 
to expose a method or setting that allows the user to specify the 
expected behaviour.
I do not think that this should be handled by the VM plugin or the 
stream class, as there are indeed different behaviours that make 
sense.


Cheers,
Max



Norbert


Am 14.07.2018 um 08:25 schrieb Max Leske :

Hi Nicolas,

The PR you are referring [1] to concerns a missing fflush() when 
truncating a file. I believe that is a different case to this one, 
as a) the file is not truncated and b) in the case of truncation 
it is an explicit requirement that the file be empty before the 
first write happens. In our case, and in general, it depends on 
the situation whether flushing must occur immediately, e.g. 
because the file will be read again immediately, or not, e.g. when 
writing a data to a backup file.


Thanks for the pointer though.


Cheers,
Max


[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271


On 12 Jul 2018, at 23:19, Nicolas Cellier wrote:

Isn't there a recent PR on opensmalltalk that address just this?

Le jeu. 12 juil. 2018 à 23:16, Max Leske  a 
écrit :


Hi Norbert,

I was able to reproduce the problem and then identify the 
culprit,
although what I don't yet understand is how this is related to 
the changes

in Zinc.

Anyway, the problem is that the file stream isn't properly 
flushed in
ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as 
the last

statement fixes your problem. Apparently, StandardFileStream /
MultiByteFileStream perform a simple close() on the file which, 
according
to the man page on close(), does *not* guarantee that the 
contents have
all been written to file. In this case a flush is necessary 
because the

entire file is immediately read again.

Here's a smaller test case for you to play with Sven:

ZnClient new
  url: 
'https://github.com/zweidenker/Parasol/archive/master.zip';

  downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ 
:s | s contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference 
binaryReadStreamDo: [ :s | s contents ]) size.


The output in the Transcript should be:

315392
318420

Cheers,
Max

On 12 Jul 2018, at 8:17, Norbert Hartl wrote:

Am 12.07.2018 um 08:05 schrieb Max Leske maxle...@gmail.com:

On 11 Jul 2018, at 22:44, Norbert Hartl wrote:

Hi Max,

I constructed a case that fails exactly like I experience it. 
Could you
try? Just unpack the attachment on a linux, set PHARO_VM env to 
your

executable and execute build.sh

I will. Might take a couple of days though.

No problem. I‘m happy if you find time.

Norbert

Max

Norbert

Am 10.07.2018 um 09:17 schrieb Max Leske maxle...@gmail.com:

On 10 Jul 2018, at 8:48, Norbert Hartl wrote:

Max,

thanks for taking the effort.

No worries.

Am 10.07.2018 um 08:37 schrieb Max Leske maxle...@gmail.com:

I did my best to reproduce the issue but didn't have any luck. I 
really
need access to a Linux VM to debug this. So I'm praying that 
Apple fixes
the access restrictions to kernel extensions in their next 
beta...


BTW, Metacello uses ZnClient, which uses ZnF

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

Just to be safe, I'll redo my experiment and get back to you.

On 21 Jul 2018, at 16:59, Sven Van Caekenberghe wrote:


I tried running Max's snippet (Pharo 6.1 on Ubuntu 16.04 LTS),

ZnClient new
url: 'https://github.com/zweidenker/Parasol/archive/master.zip';
downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | 
s contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference 
binaryReadStreamDo: [ :s | s contents ]) size.


And it gives me,

318420
318420

For me there is nothing nothing to see here ... and I have the 
impression we are all talking about different things.



On 21 Jul 2018, at 14:18, Max Leske  wrote:

On 21 Jul 2018, at 12:07, Norbert Hartl wrote:


Max,

what do you think will be a proper fix for this? I cannot see if 
this is a vm problem or not.


In my opinion it should be fixed in Zinc as there's no way for the 
user of Zinc to flush the stream. The alternative would be for Zinc 
to expose a method or setting that allows the user to specify the 
expected behaviour.
I do not think that this should be handled by the VM plugin or the 
stream class, as there are indeed different behaviours that make 
sense.


Cheers,
Max



Norbert


Am 14.07.2018 um 08:25 schrieb Max Leske :

Hi Nicolas,

The PR you are referring [1] to concerns a missing fflush() when 
truncating a file. I believe that is a different case to this one, 
as a) the file is not truncated and b) in the case of truncation it 
is an explicit requirement that the file be empty before the first 
write happens. In our case, and in general, it depends on the 
situation whether flushing must occur immediately, e.g. because the 
file will be read again immediately, or not, e.g. when writing a 
data to a backup file.


Thanks for the pointer though.


Cheers,
Max


[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271


On 12 Jul 2018, at 23:19, Nicolas Cellier wrote:

Isn't there a recent PR on opensmalltalk that address just this?

Le jeu. 12 juil. 2018 à 23:16, Max Leske  a 
écrit :


Hi Norbert,

I was able to reproduce the problem and then identify the 
culprit,
although what I don't yet understand is how this is related to 
the changes

in Zinc.

Anyway, the problem is that the file stream isn't properly 
flushed in
ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as 
the last

statement fixes your problem. Apparently, StandardFileStream /
MultiByteFileStream perform a simple close() on the file which, 
according
to the man page on close(), does *not* guarantee that the 
contents have
all been written to file. In this case a flush is necessary 
because the

entire file is immediately read again.

Here's a smaller test case for you to play with Sven:

ZnClient new
  url: 
'https://github.com/zweidenker/Parasol/archive/master.zip';

  downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ 
:s | s contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference 
binaryReadStreamDo: [ :s | s contents ]) size.


The output in the Transcript should be:

315392
318420

Cheers,
Max

On 12 Jul 2018, at 8:17, Norbert Hartl wrote:

Am 12.07.2018 um 08:05 schrieb Max Leske maxle...@gmail.com:

On 11 Jul 2018, at 22:44, Norbert Hartl wrote:

Hi Max,

I constructed a case that fails exactly like I experience it. 
Could you
try? Just unpack the attachment on a linux, set PHARO_VM env to 
your

executable and execute build.sh

I will. Might take a couple of days though.

No problem. I‘m happy if you find time.

Norbert

Max

Norbert

Am 10.07.2018 um 09:17 schrieb Max Leske maxle...@gmail.com:

On 10 Jul 2018, at 8:48, Norbert Hartl wrote:

Max,

thanks for taking the effort.

No worries.

Am 10.07.2018 um 08:37 schrieb Max Leske maxle...@gmail.com:

I did my best to reproduce the issue but didn't have any luck. I 
really
need access to a Linux VM to debug this. So I'm praying that 
Apple fixes
the access restrictions to kernel extensions in their next 
beta...


BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so 
there is
indeed a chance that something goes wrong during download of the 
zip
archive and that something may be tied to a difference in the 
versions of

Zinc (although I still think that's unlikely).

Yes there is potential but I don‘t see it. I take a fresh 6.1 
image and
load my project into. I‘m not sure but I think zinc 2.9.2 is 
loaded rather
early in that process. So I wonder why it does not go wrong in 
the first
phase. And also not if I load the test group within the first 
phase.
It must be either the second Metacello invocation or the 
stopping, copying

and starting of the image.
I try to isolate this case more and provide a script that goes 
wrong on my
machine. But it will take some time because I needed to stop 
trying to

solve this as I wasted near

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

On 21 Jul 2018, at 12:07, Norbert Hartl wrote:


Max,

what do you think will be a proper fix for this? I cannot see if this 
is a vm problem or not.


In my opinion it should be fixed in Zinc as there's no way for the user 
of Zinc to flush the stream. The alternative would be for Zinc to expose 
a method or setting that allows the user to specify the expected 
behaviour.
I do not think that this should be handled by the VM plugin or the 
stream class, as there are indeed different behaviours that make sense.


Cheers,
Max



Norbert


Am 14.07.2018 um 08:25 schrieb Max Leske :

Hi Nicolas,

The PR you are referring [1] to concerns a missing fflush() when 
truncating a file. I believe that is a different case to this one, as 
a) the file is not truncated and b) in the case of truncation it is 
an explicit requirement that the file be empty before the first write 
happens. In our case, and in general, it depends on the situation 
whether flushing must occur immediately, e.g. because the file will 
be read again immediately, or not, e.g. when writing a data to a 
backup file.


Thanks for the pointer though.


Cheers,
Max


[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271


On 12 Jul 2018, at 23:19, Nicolas Cellier wrote:

Isn't there a recent PR on opensmalltalk that address just this?

Le jeu. 12 juil. 2018 à 23:16, Max Leske  a 
écrit :


Hi Norbert,

I was able to reproduce the problem and then identify the culprit,
although what I don't yet understand is how this is related to the 
changes

in Zinc.

Anyway, the problem is that the file stream isn't properly flushed 
in
ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as 
the last

statement fixes your problem. Apparently, StandardFileStream /
MultiByteFileStream perform a simple close() on the file which, 
according
to the man page on close(), does *not* guarantee that the contents 
have
all been written to file. In this case a flush is necessary because 
the

entire file is immediately read again.

Here's a smaller test case for you to play with Sven:

ZnClient new
   url: 'https://github.com/zweidenker/Parasol/archive/master.zip';
   downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s 
| s contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference 
binaryReadStreamDo: [ :s | s contents ]) size.


The output in the Transcript should be:

315392
318420

Cheers,
Max

On 12 Jul 2018, at 8:17, Norbert Hartl wrote:

Am 12.07.2018 um 08:05 schrieb Max Leske maxle...@gmail.com:

On 11 Jul 2018, at 22:44, Norbert Hartl wrote:

Hi Max,

I constructed a case that fails exactly like I experience it. Could 
you
try? Just unpack the attachment on a linux, set PHARO_VM env to 
your

executable and execute build.sh

I will. Might take a couple of days though.

No problem. I‘m happy if you find time.

Norbert

Max

Norbert

Am 10.07.2018 um 09:17 schrieb Max Leske maxle...@gmail.com:

On 10 Jul 2018, at 8:48, Norbert Hartl wrote:

Max,

thanks for taking the effort.

No worries.

Am 10.07.2018 um 08:37 schrieb Max Leske maxle...@gmail.com:

I did my best to reproduce the issue but didn't have any luck. I 
really
need access to a Linux VM to debug this. So I'm praying that Apple 
fixes

the access restrictions to kernel extensions in their next beta...

BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so 
there is
indeed a chance that something goes wrong during download of the 
zip
archive and that something may be tied to a difference in the 
versions of

Zinc (although I still think that's unlikely).

Yes there is potential but I don‘t see it. I take a fresh 6.1 
image and
load my project into. I‘m not sure but I think zinc 2.9.2 is 
loaded rather
early in that process. So I wonder why it does not go wrong in the 
first
phase. And also not if I load the test group within the first 
phase.
It must be either the second Metacello invocation or the stopping, 
copying

and starting of the image.
I try to isolate this case more and provide a script that goes 
wrong on my
machine. But it will take some time because I needed to stop trying 
to

solve this as I wasted nearly two days on that already.

Let me know once you have something and I'll try to help out.

Norbert

Max

On 9 Jul 2018, at 19:43, Norbert Hartl wrote:

Am 09.07.2018 um 19:10 schrieb Max Leske maxle...@gmail.com:

I checked the Parasol Archive and it does not appear to be in Zip64 
format
(Metacello uses ZipArchive which can't cope with Zip64 but 
ZipArchive can
read the Parasol zip). So my next guess is that there's either a 
problem
with Metacello or Pharo in the way that ZipArchive is used (e.g. 
endianness
problem or non-binary stream data). It would therefore be helpful 
to find
out what happens in ZipArchive>>readFrom:, i.e. what kind of stream 
is
passed / opened, is it binary, does the file exist and is it still 
the

corr

Re: [Pharo-dev] ZnUnicodeComposingReadStream?

[Max Leske]

On 16 Jul 2018, at 19:46, Alistair Grant wrote:


Hi Sven & Max,


On Fri, Jul 13, 2018 at 07:59:32PM +0200, Sven Van Caekenberghe wrote:

Alistair, are you aware of the following (article/codebase) ?

  
https://medium.com/concerning-pharo/an-implementation-of-unicode-normalization-7c6719068f43

Due to the size of the full DB it is doubtful it would become a 
standard part of Pharo though.


Sven



Thanks again for the link, it has helped my (still limited)
understanding of Unicode.

The reason I started looking in to this was that my file attribute
modification tests failed on Mac OS.  The problem is that Mac OS
requires file names to be decomposed UTF8, and my plugin wasn't doing
the conversion.

Following the general principle of trying to keep the VM minimal and 
do

as much as possible in the image, I had hoped I could do the UTF8
(de)composition in the image.

But it turns out that Mac OS doesn't follow the standard rules, so
programs really need to use the native file name encoding routines on
Mac OS.

So that's the path I'll be following in this instance.  I still really
appreciate the link, and will be exploring the Unicode package more.



On Fri, Jul 13, 2018 at 10:50:36PM +0200, Max Leske wrote:

Hi Alistair,

*nix systems usually come with the iconv[1] command line program that
implements the normalization and denormalization algorithms, or Uconv 
2, a
library that does the same thing. These algorithms include a lot of 
black magic
and I recommend to not make your hands dirty with them. With the FFI 
interface
Pharo has today it shouldn't be too hard to call out to Uconv 
(although I'm not
saying it's trivial; I've written a VM plugin that we use a work to 
interface
with Uconv and you do have to know how encodings and iconv work) or 
execute

iconv directly.

I can send you a copy of the plugin code if you want, actually, I may 
put it on

github if there's interest.

Cheers,
Max

[1] https://linux.die.net/man/1/iconv
[2] https://en.wikipedia.org/wiki/Uconv
[3] http://site.icu-project.org/




On Sat, Jul 14, 2018 at 08:20:23AM +0200, Max Leske wrote:
I realize I got things mixed up a bit: Uconv is a program akin to 
Iconv. What

we interface with is libicu.

Max


The VM already uses libiconv for the encoding translation on linux.  
As

far as I know, the routines haven't been exposed directly to the image
(although I haven't looked carefully).

I'd be interested in looking at your plugin - I'm still working 
through
the current FilePlugin behaviour, but I think it would be useful to 
have

these routines available directly from the image for debugging, etc.

Thanks again,
Alistair


I've put the plugin source on Github: 
https://github.com/Netstyle/Squeak-VM-Unicode-operations-plugin.


I hope you'll find it useful. Note that the code was written for version 
4.0.3-2202 of the Squeak VM and that you'd most likely have to make a 
couple of modifications to get it running in the OpenSmalltalk VM's.



Cheers,
Max

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

Hi Nicolas,

The PR you are referring [1] to concerns a missing fflush() when 
truncating a file. I believe that is a different case to this one, as a) 
the file is not truncated and b) in the case of truncation it is an 
explicit requirement that the file be empty before the first write 
happens. In our case, and in general, it depends on the situation 
whether flushing must occur immediately, e.g. because the file will be 
read again immediately, or not, e.g. when writing a data to a backup 
file.


Thanks for the pointer though.


Cheers,
Max


[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271

On 12 Jul 2018, at 23:19, Nicolas Cellier wrote:


Isn't there a recent PR on opensmalltalk that address just this?

Le jeu. 12 juil. 2018 à 23:16, Max Leske  a 
écrit :



Hi Norbert,

I was able to reproduce the problem and then identify the culprit,
although what I don't yet understand is how this is related to the 
changes

in Zinc.

Anyway, the problem is that the file stream isn't properly flushed in
ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as the 
last

statement fixes your problem. Apparently, StandardFileStream /
MultiByteFileStream perform a simple close() on the file which, 
according
to the man page on close(), does *not* guarantee that the contents 
have
all been written to file. In this case a flush is necessary because 
the

entire file is immediately read again.

Here's a smaller test case for you to play with Sven:

ZnClient new
url: 'https://github.com/zweidenker/Parasol/archive/master.zip';
downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | 
s contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference 
binaryReadStreamDo: [ :s | s contents ]) size.


The output in the Transcript should be:

315392
318420

Cheers,
Max

On 12 Jul 2018, at 8:17, Norbert Hartl wrote:

Am 12.07.2018 um 08:05 schrieb Max Leske maxle...@gmail.com:

On 11 Jul 2018, at 22:44, Norbert Hartl wrote:

Hi Max,

I constructed a case that fails exactly like I experience it. Could 
you

try? Just unpack the attachment on a linux, set PHARO_VM env to your
executable and execute build.sh

I will. Might take a couple of days though.

No problem. I‘m happy if you find time.

Norbert

Max

Norbert

Am 10.07.2018 um 09:17 schrieb Max Leske maxle...@gmail.com:

On 10 Jul 2018, at 8:48, Norbert Hartl wrote:

Max,

thanks for taking the effort.

No worries.

Am 10.07.2018 um 08:37 schrieb Max Leske maxle...@gmail.com:

I did my best to reproduce the issue but didn't have any luck. I 
really
need access to a Linux VM to debug this. So I'm praying that Apple 
fixes

the access restrictions to kernel extensions in their next beta...

BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there 
is

indeed a chance that something goes wrong during download of the zip
archive and that something may be tied to a difference in the 
versions of

Zinc (although I still think that's unlikely).

Yes there is potential but I don‘t see it. I take a fresh 6.1 image 
and
load my project into. I‘m not sure but I think zinc 2.9.2 is loaded 
rather
early in that process. So I wonder why it does not go wrong in the 
first

phase. And also not if I load the test group within the first phase.
It must be either the second Metacello invocation or the stopping, 
copying

and starting of the image.
I try to isolate this case more and provide a script that goes wrong 
on my
machine. But it will take some time because I needed to stop trying 
to

solve this as I wasted nearly two days on that already.

Let me know once you have something and I'll try to help out.

Norbert

Max

On 9 Jul 2018, at 19:43, Norbert Hartl wrote:

Am 09.07.2018 um 19:10 schrieb Max Leske maxle...@gmail.com:

I checked the Parasol Archive and it does not appear to be in Zip64 
format
(Metacello uses ZipArchive which can't cope with Zip64 but ZipArchive 
can
read the Parasol zip). So my next guess is that there's either a 
problem
with Metacello or Pharo in the way that ZipArchive is used (e.g. 
endianness
problem or non-binary stream data). It would therefore be helpful to 
find
out what happens in ZipArchive>>readFrom:, i.e. what kind of stream 
is
passed / opened, is it binary, does the file exist and is it still 
the

correct file.

I couldn’t see anything obvious. The file in the debug message 
exists, it

is a readable zip file. The way Metacello uses it it is a
StandardFileStream. It switches it to binary in the code.
But the only difference between a working and non-working build is 
the

upgrade to zinc 2.9.2.

Norbert

I'd debug it myself but I can't run VirtualBox at the moment because 
I'm

on the macOS beta and it won't start...

Max

On 9 Jul 2018, at 18:31, Norbert Hartl wrote:

Hi Max,

Am 09.07.2018 um 18:18 schrieb Max Leske maxle...@gmail.com:

Hi Norbert,

This is a bit of a guess, but i

Re: [Pharo-dev] ZnUnicodeComposingReadStream?

[Max Leske]

I realize I got things mixed up a bit: Uconv is a program akin to Iconv. 
What we interface with is libicu.


Max

On 13 Jul 2018, at 22:50, Max Leske wrote:


Hi Alistair,

*nix systems usually come with the iconv[1] command line program that 
implements the normalization and denormalization algorithms, or Uconv 
[2] (from ICU [3]), a library that does the same thing. These 
algorithms include a lot of black magic and I recommend to not make 
your hands dirty with them. With the FFI interface Pharo has today it 
shouldn't be too hard to call out to Uconv (although I'm not saying 
it's trivial; I've written a VM plugin that we use a work to interface 
with Uconv and you do have to know how encodings and iconv work) or 
execute iconv directly.


I can send you a copy of the plugin code if you want, actually, I may 
put it on github if there's interest.


Cheers,
Max

[1] https://linux.die.net/man/1/iconv
[2] https://en.wikipedia.org/wiki/Uconv
[3] http://site.icu-project.org/


On 13 Jul 2018, at 20:22, Alistair Grant wrote:


Hi Sven,

Thanks very much for your quick reply...

On Fri, 13 Jul 2018 at 19:59, Sven Van Caekenberghe  
wrote:


Alistair, are you aware of the following (article/codebase) ?

  
https://medium.com/concerning-pharo/an-implementation-of-unicode-normalization-7c6719068f43

Due to the size of the full DB it is doubtful it would become a 
standard part of Pharo though.


Sven


I hadn't seen this.  I'll read it next (although I think it will take
me longer than 17 minutes :-)).

But a quick, partial answer is that I was planning on only supporting
the composition and decomposition tables that are already included in
the main image as part of CombinedChar (see the Composition and
Decomposition class variables).

Thanks again,
Alistair


On 13 Jul 2018, at 19:46, Alistair Grant  
wrote:


Hi Sven & Everyone,

I need to convert an UTF8 encoded decomposed stream (Mac OS file
names) in to a composed string, e.g.:

string: 'test-äöü-äöü'
code points: #(116 101 115 116 45 228 246 252 45 97 776 111 776 117 
776)
utf8 encoding: #[116 101 115 116 45 195 164 195 182 195 188 45 97 
204

136 111 204 136 117 204 136]

In the above string, the first group of 3 accented characters are 
the

same as the second group of 3, but are encoded differently - code
points (228 246 252) vs (97 776 111 776 117 776).

Reading the utf8 encoded stream should result in:

string: 'test-äöü-äöü'
code points: #(116 101 115 116 45 228 246 252 45 228 246 252)
utf8 encoding: #[116 101 115 116 45 195 164 195 182 195 188 45 195 
164

195 182 195 188]

My current thought is to write a ZnUnicodeComposingReadStream which
would wrap a ZnCharacterReadStream and return the composed 
characters.


What do you think?

Thanks!
Alistair

Re: [Pharo-dev] ZnUnicodeComposingReadStream?

[Max Leske]

Hi Alistair,

*nix systems usually come with the iconv[1] command line program that 
implements the normalization and denormalization algorithms, or Uconv 
[2] (from ICU [3]), a library that does the same thing. These algorithms 
include a lot of black magic and I recommend to not make your hands 
dirty with them. With the FFI interface Pharo has today it shouldn't be 
too hard to call out to Uconv (although I'm not saying it's trivial; 
I've written a VM plugin that we use a work to interface with Uconv and 
you do have to know how encodings and iconv work) or execute iconv 
directly.


I can send you a copy of the plugin code if you want, actually, I may 
put it on github if there's interest.


Cheers,
Max

[1] https://linux.die.net/man/1/iconv
[2] https://en.wikipedia.org/wiki/Uconv
[3] http://site.icu-project.org/


On 13 Jul 2018, at 20:22, Alistair Grant wrote:


Hi Sven,

Thanks very much for your quick reply...

On Fri, 13 Jul 2018 at 19:59, Sven Van Caekenberghe  
wrote:


Alistair, are you aware of the following (article/codebase) ?

  
https://medium.com/concerning-pharo/an-implementation-of-unicode-normalization-7c6719068f43

Due to the size of the full DB it is doubtful it would become a 
standard part of Pharo though.


Sven


I hadn't seen this.  I'll read it next (although I think it will take
me longer than 17 minutes :-)).

But a quick, partial answer is that I was planning on only supporting
the composition and decomposition tables that are already included in
the main image as part of CombinedChar (see the Composition and
Decomposition class variables).

Thanks again,
Alistair


On 13 Jul 2018, at 19:46, Alistair Grant  
wrote:


Hi Sven & Everyone,

I need to convert an UTF8 encoded decomposed stream (Mac OS file
names) in to a composed string, e.g.:

string: 'test-äöü-äöü'
code points: #(116 101 115 116 45 228 246 252 45 97 776 111 776 117 
776)
utf8 encoding: #[116 101 115 116 45 195 164 195 182 195 188 45 97 
204

136 111 204 136 117 204 136]

In the above string, the first group of 3 accented characters are 
the

same as the second group of 3, but are encoded differently - code
points (228 246 252) vs (97 776 111 776 117 776).

Reading the utf8 encoded stream should result in:

string: 'test-äöü-äöü'
code points: #(116 101 115 116 45 228 246 252 45 228 246 252)
utf8 encoding: #[116 101 115 116 45 195 164 195 182 195 188 45 195 
164

195 182 195 188]

My current thought is to write a ZnUnicodeComposingReadStream which
would wrap a ZnCharacterReadStream and return the composed 
characters.


What do you think?

Thanks!
Alistair

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

On 13 Jul 2018, at 13:37, Norbert Hartl wrote:


Sven,

for me the problem is only on linux


Yes, exactly. The problem doesn't exist on macOS. I tested on Ubuntu 
17.04 (32-bit).




Norbert


Am 13.07.2018 um 13:26 schrieb Sven Van Caekenberghe :




On 12 Jul 2018, at 23:15, Max Leske  wrote:

Hi Norbert,

I was able to reproduce the problem and then identify the culprit, 
although what I don't yet understand is how this is related to the 
changes in Zinc.


Anyway, the problem is that the file stream isn't properly flushed 
in ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as 
the last statement fixes your problem. Apparently, 
StandardFileStream / MultiByteFileStream perform a simple close() on 
the file which, according to the man page on close(), does not 
guarantee that the contents have all been written to file. In this 
case a flush is necessary because the entire file is immediately 
read again.


Here's a smaller test case for you to play with Sven:

ZnClient new
   url: 'https://github.com/zweidenker/Parasol/archive/master.zip';
   downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s 
| s contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference 
binaryReadStreamDo: [ :s | s contents ]) size.


The output in the Transcript should be:

315392
318420


Thanks for the effort, Max, but I am confused about your runnable 
snippet. For me (macOS, Pharo 7) is gives


318420
318420

as it should, reading the same file twice. Did I miss something or 
did you make a typo ?


As for #close, it is my understanding that Pharo did a #flush before 
doing a #close, but maybe that is no longer true with the new 
primitive streams, we'll have to check carefully.


Good catch. I'll think about your suggestion (there are already 
#flush messages sent, but indeed the last one would be missing).



Cheers,
Max

On 12 Jul 2018, at 8:17, Norbert Hartl wrote:

Am 12.07.2018 um 08:05 schrieb Max Leske maxle...@gmail.com:

On 11 Jul 2018, at 22:44, Norbert Hartl wrote:

Hi Max,

I constructed a case that fails exactly like I experience it. Could 
you try? Just unpack the attachment on a linux, set PHARO_VM env to 
your executable and execute build.sh


I will. Might take a couple of days though.

No problem. I‘m happy if you find time.

Norbert

Max

Norbert

Am 10.07.2018 um 09:17 schrieb Max Leske maxle...@gmail.com:

On 10 Jul 2018, at 8:48, Norbert Hartl wrote:

Max,

thanks for taking the effort.

No worries.

Am 10.07.2018 um 08:37 schrieb Max Leske maxle...@gmail.com:

I did my best to reproduce the issue but didn't have any luck. I 
really need access to a Linux VM to debug this. So I'm praying that 
Apple fixes the access restrictions to kernel extensions in their 
next beta...


BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there 
is indeed a chance that something goes wrong during download of the 
zip archive and that something may be tied to a difference in the 
versions of Zinc (although I still think that's unlikely).


Yes there is potential but I don‘t see it. I take a fresh 6.1 
image and load my project into. I‘m not sure but I think zinc 
2.9.2 is loaded rather early in that process. So I wonder why it 
does not go wrong in the first phase. And also not if I load the 
test group within the first phase.
It must be either the second Metacello invocation or the stopping, 
copying and starting of the image.
I try to isolate this case more and provide a script that goes wrong 
on my machine. But it will take some time because I needed to stop 
trying to solve this as I wasted nearly two days on that already.


Let me know once you have something and I'll try to help out.

Norbert

Max

On 9 Jul 2018, at 19:43, Norbert Hartl wrote:

Am 09.07.2018 um 19:10 schrieb Max Leske maxle...@gmail.com:

I checked the Parasol Archive and it does not appear to be in Zip64 
format (Metacello uses ZipArchive which can't cope with Zip64 but 
ZipArchive can read the Parasol zip). So my next guess is that 
there's either a problem with Metacello or Pharo in the way that 
ZipArchive is used (e.g. endianness problem or non-binary stream 
data). It would therefore be helpful to find out what happens in 
ZipArchive>>readFrom:, i.e. what kind of stream is passed / opened, 
is it binary, does the file exist and is it still the correct file.


I couldn’t see anything obvious. The file in the debug message 
exists, it is a readable zip file. The way Metacello uses it it is a 
StandardFileStream. It switches it to binary in the code.
But the only difference between a working and non-working build is 
the upgrade to zinc 2.9.2.


Norbert

I'd debug it myself but I can't run VirtualBox at the moment because 
I'm on the macOS beta and it won't start...


Max

On 9 Jul 2018, at 18:31, Norbert Hartl wrote:

Hi Max,

Am 09.07.2018 um 18:18 schrieb Max Leske maxle...@gmail.com:

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

Hi Norbert,

I was able to reproduce the problem and then identify the culprit, 
although what I don't yet understand is how this is related to the 
changes in Zinc.


Anyway, the problem is that the file stream isn't properly flushed in 
ZnUtils class>>streamFrom:to:size:. Adding `outputStream flush` as the 
last statement fixes your problem. Apparently, StandardFileStream / 
MultiByteFileStream perform a simple `close()` on the file which, 
according to the man page on `close()`, does *not* guarantee that the 
contents have all been written to file. In this case a flush is 
necessary because the entire file is immediately read again.


Here's a smaller test case for you to play with Sven:

```
ZnClient new
url: 'https://github.com/zweidenker/Parasol/archive/master.zip';
downloadTo: '/tmp/foobar.zip'.
bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s 
contents ].

Transcript open; show: bytes size; cr.
5 seconds asDelay wait.
Transcript show: ('/tmp/foobar.zip' asFileReference binaryReadStreamDo: 
[ :s | s contents ]) size.

```

The output in the Transcript should be:

```
315392
318420
```

Cheers,
Max


On 12 Jul 2018, at 8:17, Norbert Hartl wrote:


Am 12.07.2018 um 08:05 schrieb Max Leske :


On 11 Jul 2018, at 22:44, Norbert Hartl wrote:

Hi Max,

I constructed a case that fails exactly like I experience it. Could 
you try? Just unpack the attachment on a linux, set PHARO_VM env to 
your executable and execute build.sh


I will. Might take a couple of days though.


No problem. I‘m happy if you find time.

Norbert

Max



Norbert


Am 10.07.2018 um 09:17 schrieb Max Leske :

On 10 Jul 2018, at 8:48, Norbert Hartl wrote:


Max,

thanks for taking the effort.


No worries.




Am 10.07.2018 um 08:37 schrieb Max Leske :

I did my best to reproduce the issue but didn't have any luck. I 
really need access to a Linux VM to debug this. So I'm praying 
that Apple fixes the access restrictions to kernel extensions in 
their next beta...


BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so 
there is indeed a chance that something goes wrong during 
download of the zip archive and that something may be tied to a 
difference in the versions of Zinc (although I still think that's 
unlikely).


Yes there is potential but I don‘t see it. I take a fresh 6.1 
image and load my project into. I‘m not sure but I think zinc 
2.9.2 is loaded rather early in that process. So I wonder why it 
does not go wrong in the first phase. And also not if I load the 
test group within the first phase.
It must be either the second Metacello invocation or the stopping, 
copying and starting of the image.
I try to isolate this case more and provide a script that goes 
wrong on my machine. But it will take some time because I needed 
to stop trying to solve this as I wasted nearly two days on that 
already.


Let me know once you have something and I'll try to help out.



Norbert


Max


On 9 Jul 2018, at 19:43, Norbert Hartl wrote:




Am 09.07.2018 um 19:10 schrieb Max Leske :

I checked the Parasol Archive and it does not appear to be in 
Zip64 format (Metacello uses ZipArchive which can't cope with 
Zip64 but ZipArchive can read the Parasol zip). So my next guess 
is that there's either a problem with Metacello or Pharo in the 
way that ZipArchive is used (e.g. endianness problem or 
non-binary stream data). It would therefore be helpful to find 
out what happens in ZipArchive>>readFrom:, i.e. what kind of 
stream is passed / opened, is it binary, does the file exist and 
is it still the correct file.



I couldn’t see anything obvious. The file in the debug message 
exists, it is a readable zip file. The way Metacello uses it it 
is a StandardFileStream. It switches it to binary in the code.
But the only difference between a working and non-working build 
is the upgrade to zinc 2.9.2.


Norbert

I'd debug it myself but I can't run VirtualBox at the moment 
because I'm on the macOS beta and it won't start...


Max

On 9 Jul 2018, at 18:31, Norbert Hartl wrote:

Hi Max,



Am 09.07.2018 um 18:18 schrieb Max Leske :

Hi Norbert,

This is a bit of a guess, but it's possible that the archive 
that is downloaded from github is in Zip64 format and that the 
libraries for extracting Zip64 are missing on your Linux. That 
would of course contradict the experience that the same 
operation appears to work in 6.1.



to be honest I don’t know what Zip64 format is. I thought the 
Zip classes are pure smalltalk for unpacking.
Try extracting the archive manually on your Linux machine with 
the same method that Metacello uses (I assume, Metacello uses 
the ZipPlugin, which will probably use the system libraries).





I have no ZipPlugin as library in any of my vms.

But there are zips downloaded and unpacked. I start the image 
the first time loading all the code of my project. Then it is 
saved, copied to a new name and reopened to load the tests and 
then it fails. I did try to lo

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

On 11 Jul 2018, at 22:44, Norbert Hartl wrote:


Hi Max,

I constructed a case that fails exactly like I experience it. Could 
you try? Just unpack the attachment on a linux, set PHARO_VM env to 
your executable and execute build.sh


I will. Might take a couple of days though.

Max



Norbert


Am 10.07.2018 um 09:17 schrieb Max Leske :

On 10 Jul 2018, at 8:48, Norbert Hartl wrote:


Max,

thanks for taking the effort.


No worries.




Am 10.07.2018 um 08:37 schrieb Max Leske :

I did my best to reproduce the issue but didn't have any luck. I 
really need access to a Linux VM to debug this. So I'm praying that 
Apple fixes the access restrictions to kernel extensions in their 
next beta...


BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so 
there is indeed a chance that something goes wrong during download 
of the zip archive and that something may be tied to a difference 
in the versions of Zinc (although I still think that's unlikely).


Yes there is potential but I don‘t see it. I take a fresh 6.1 
image and load my project into. I‘m not sure but I think zinc 
2.9.2 is loaded rather early in that process. So I wonder why it 
does not go wrong in the first phase. And also not if I load the 
test group within the first phase.
It must be either the second Metacello invocation or the stopping, 
copying and starting of the image.
I try to isolate this case more and provide a script that goes wrong 
on my machine. But it will take some time because I needed to stop 
trying to solve this as I wasted nearly two days on that already.


Let me know once you have something and I'll try to help out.



Norbert


Max


On 9 Jul 2018, at 19:43, Norbert Hartl wrote:




Am 09.07.2018 um 19:10 schrieb Max Leske :

I checked the Parasol Archive and it does not appear to be in 
Zip64 format (Metacello uses ZipArchive which can't cope with 
Zip64 but ZipArchive can read the Parasol zip). So my next guess 
is that there's either a problem with Metacello or Pharo in the 
way that ZipArchive is used (e.g. endianness problem or non-binary 
stream data). It would therefore be helpful to find out what 
happens in ZipArchive>>readFrom:, i.e. what kind of stream is 
passed / opened, is it binary, does the file exist and is it still 
the correct file.



I couldn’t see anything obvious. The file in the debug message 
exists, it is a readable zip file. The way Metacello uses it it is 
a StandardFileStream. It switches it to binary in the code.
But the only difference between a working and non-working build is 
the upgrade to zinc 2.9.2.


Norbert

I'd debug it myself but I can't run VirtualBox at the moment 
because I'm on the macOS beta and it won't start...


Max

On 9 Jul 2018, at 18:31, Norbert Hartl wrote:

Hi Max,



Am 09.07.2018 um 18:18 schrieb Max Leske :

Hi Norbert,

This is a bit of a guess, but it's possible that the archive that 
is downloaded from github is in Zip64 format and that the 
libraries for extracting Zip64 are missing on your Linux. That 
would of course contradict the experience that the same operation 
appears to work in 6.1.



to be honest I don’t know what Zip64 format is. I thought the 
Zip classes are pure smalltalk for unpacking.
Try extracting the archive manually on your Linux machine with 
the same method that Metacello uses (I assume, Metacello uses the 
ZipPlugin, which will probably use the system libraries).





I have no ZipPlugin as library in any of my vms.

But there are zips downloaded and unpacked. I start the image the 
first time loading all the code of my project. Then it is saved, 
copied to a new name and reopened to load the tests and then it 
fails. I did try to load the tests in the first run and then it 
works.


I’m running out of ideas

thanks,

Norbert

Cheers,
Max


On 9 Jul 2018, at 17:14, Norbert Hartl wrote:

With the help of Esteban I got one step further. If I do

MCWorkingCopy
   managersForClass: ZnFileSystemUtils
   do: [ :each | each ancestry initialize ]

before loading my project it updates Zinc-FileSystem as well. 
Sadly it still does not work for me because I get


Loading baseline of BaselineOfMobilityMap...
...RETRY->BaselineOfParasol
...RETRY->BaselineOfParasolError: can't find EOCD position

and I don’t know why. zip file is downloaded from github and 
present but it fails and only on my jenkins on linux. On my Mac 
this works.


I try a few things but then I’m back on pharo6.1 for the time 
being :(


Norbert


Am 07.07.2018 um 13:28 schrieb Norbert Hartl 
:


Really? I thought the same but then I didn’t believe it works 
like that.


Anyway this would be very easy to solve. We just need to ask 
Sven if he is fine with doing an empty .16 version for 
Zinc-FileSystem and does an in-place version reset of 2.9.2 or a 
new 2.9.3. I’m not fully convinced that will solve it but the 
cost won’t be very high.


Norbert


Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot 
:





Need to investigate more. There are two 

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

On 10 Jul 2018, at 8:48, Norbert Hartl wrote:


Max,

thanks for taking the effort.


No worries.




Am 10.07.2018 um 08:37 schrieb Max Leske :

I did my best to reproduce the issue but didn't have any luck. I 
really need access to a Linux VM to debug this. So I'm praying that 
Apple fixes the access restrictions to kernel extensions in their 
next beta...


BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there 
is indeed a chance that something goes wrong during download of the 
zip archive and that something may be tied to a difference in the 
versions of Zinc (although I still think that's unlikely).


Yes there is potential but I don‘t see it. I take a fresh 6.1 image 
and load my project into. I‘m not sure but I think zinc 2.9.2 is 
loaded rather early in that process. So I wonder why it does not go 
wrong in the first phase. And also not if I load the test group within 
the first phase.
It must be either the second Metacello invocation or the stopping, 
copying and starting of the image.
I try to isolate this case more and provide a script that goes wrong 
on my machine. But it will take some time because I needed to stop 
trying to solve this as I wasted nearly two days on that already.


Let me know once you have something and I'll try to help out.



Norbert


Max


On 9 Jul 2018, at 19:43, Norbert Hartl wrote:




Am 09.07.2018 um 19:10 schrieb Max Leske :

I checked the Parasol Archive and it does not appear to be in Zip64 
format (Metacello uses ZipArchive which can't cope with Zip64 but 
ZipArchive can read the Parasol zip). So my next guess is that 
there's either a problem with Metacello or Pharo in the way that 
ZipArchive is used (e.g. endianness problem or non-binary stream 
data). It would therefore be helpful to find out what happens in 
ZipArchive>>readFrom:, i.e. what kind of stream is passed / opened, 
is it binary, does the file exist and is it still the correct file.



I couldn’t see anything obvious. The file in the debug message 
exists, it is a readable zip file. The way Metacello uses it it is a 
StandardFileStream. It switches it to binary in the code.
But the only difference between a working and non-working build is 
the upgrade to zinc 2.9.2.


Norbert

I'd debug it myself but I can't run VirtualBox at the moment because 
I'm on the macOS beta and it won't start...


Max

On 9 Jul 2018, at 18:31, Norbert Hartl wrote:

Hi Max,



Am 09.07.2018 um 18:18 schrieb Max Leske :

Hi Norbert,

This is a bit of a guess, but it's possible that the archive that 
is downloaded from github is in Zip64 format and that the libraries 
for extracting Zip64 are missing on your Linux. That would of 
course contradict the experience that the same operation appears to 
work in 6.1.



to be honest I don’t know what Zip64 format is. I thought the Zip 
classes are pure smalltalk for unpacking.
Try extracting the archive manually on your Linux machine with the 
same method that Metacello uses (I assume, Metacello uses the 
ZipPlugin, which will probably use the system libraries).





I have no ZipPlugin as library in any of my vms.

But there are zips downloaded and unpacked. I start the image the 
first time loading all the code of my project. Then it is saved, 
copied to a new name and reopened to load the tests and then it 
fails. I did try to load the tests in the first run and then it 
works.


I’m running out of ideas

thanks,

Norbert

Cheers,
Max


On 9 Jul 2018, at 17:14, Norbert Hartl wrote:

With the help of Esteban I got one step further. If I do

MCWorkingCopy
managersForClass: ZnFileSystemUtils
do: [ :each | each ancestry initialize ]

before loading my project it updates Zinc-FileSystem as well. Sadly 
it still does not work for me because I get


Loading baseline of BaselineOfMobilityMap...
...RETRY->BaselineOfParasol
...RETRY->BaselineOfParasolError: can't find EOCD position

and I don’t know why. zip file is downloaded from github and 
present but it fails and only on my jenkins on linux. On my Mac 
this works.


I try a few things but then I’m back on pharo6.1 for the time 
being :(


Norbert



Am 07.07.2018 um 13:28 schrieb Norbert Hartl :

Really? I thought the same but then I didn’t believe it works 
like that.


Anyway this would be very easy to solve. We just need to ask Sven 
if he is fine with doing an empty .16 version for Zinc-FileSystem 
and does an in-place version reset of 2.9.2 or a new 2.9.3. I’m 
not fully convinced that will solve it but the cost won’t be 
very high.


Norbert


Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot 
:





Need to investigate more. There are two .15 versions but there 
is 1 year in between (if you didn’t notice TheIntegratior.15 
is from 2017). Just want to have more context information 
because I can only see that this is strange but lacking insight.


I’m trying to figure out why it does not update 
Zinc-FileSystem. No matter what I do I cannot get Metacello to 
load the n

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

I did my best to reproduce the issue but didn't have any luck. I really 
need access to a Linux VM to debug this. So I'm praying that Apple fixes 
the access restrictions to kernel extensions in their next beta...


BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there is 
indeed a chance that something goes wrong during download of the zip 
archive and that something may be tied to a difference in the versions 
of Zinc (although I still think that's unlikely).


Cheers,
Max


On 9 Jul 2018, at 19:43, Norbert Hartl wrote:


> Am 09.07.2018 um 19:10 schrieb Max Leske :


I checked the Parasol Archive and it does not appear to be in Zip64 
format (Metacello uses ZipArchive which can't cope with Zip64 but 
ZipArchive can read the Parasol zip). So my next guess is that 
there's either a problem with Metacello or Pharo in the way that 
ZipArchive is used (e.g. endianness problem or non-binary stream 
data). It would therefore be helpful to find out what happens in 
ZipArchive>>readFrom:, i.e. what kind of stream is passed / opened, 
is it binary, does the file exist and is it still the correct file.



I couldn’t see anything obvious. The file in the debug message 
exists, it is a readable zip file. The way Metacello uses it it is a 
StandardFileStream. It switches it to binary in the code.
But the only difference between a working and non-working build is the 
upgrade to zinc 2.9.2.


Norbert

I'd debug it myself but I can't run VirtualBox at the moment because 
I'm on the macOS beta and it won't start...


Max

On 9 Jul 2018, at 18:31, Norbert Hartl wrote:

Hi Max,


Am 09.07.2018 um 18:18 schrieb Max Leske <mailto:maxle...@gmail.com>>:


Hi Norbert,

This is a bit of a guess, but it's possible that the archive that is 
downloaded from github is in Zip64 format and that the libraries for 
extracting Zip64 are missing on your Linux. That would of course 
contradict the experience that the same operation appears to work in 
6.1.



to be honest I don’t know what Zip64 format is. I thought the Zip 
classes are pure smalltalk for unpacking.
Try extracting the archive manually on your Linux machine with the 
same method that Metacello uses (I assume, Metacello uses the 
ZipPlugin, which will probably use the system libraries).





I have no ZipPlugin as library in any of my vms.

But there are zips downloaded and unpacked. I start the image the 
first time loading all the code of my project. Then it is saved, 
copied to a new name and reopened to load the tests and then it 
fails. I did try to load the tests in the first run and then it 
works.


I’m running out of ideas

thanks,

Norbert

Cheers,
Max


On 9 Jul 2018, at 17:14, Norbert Hartl wrote:

With the help of Esteban I got one step further. If I do

MCWorkingCopy
managersForClass: ZnFileSystemUtils
do: [ :each | each ancestry initialize ]

before loading my project it updates Zinc-FileSystem as well. Sadly 
it still does not work for me because I get


Loading baseline of BaselineOfMobilityMap...
...RETRY->BaselineOfParasol
...RETRY->BaselineOfParasolError: can't find EOCD position

and I don’t know why. zip file is downloaded from github and 
present but it fails and only on my jenkins on linux. On my Mac this 
works.


I try a few things but then I’m back on pharo6.1 for the time 
being :(


Norbert


Am 07.07.2018 um 13:28 schrieb Norbert Hartl <mailto:norb...@hartl.name>>:


Really? I thought the same but then I didn’t believe it works 
like that.


Anyway this would be very easy to solve. We just need to ask Sven 
if he is fine with doing an empty .16 version for Zinc-FileSystem 
and does an in-place version reset of 2.9.2 or a new 2.9.3. I’m 
not fully convinced that will solve it but the cost won’t be very 
high.


Norbert


Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot 
mailto:cyril.ferli...@gmail.com>>:



Need to investigate more. There are two .15 versions but there is 
1 year in between (if you didn’t notice TheIntegratior.15 is 
from 2017). Just want to have more context information because I 
can only see that this is strange but lacking insight.


I’m trying to figure out why it does not update Zinc-FileSystem. 
No matter what I do I cannot get Metacello to load the newer 
package. That would fix the issue because I’m loading 2.9.2 
which should have Zinc-FileSystem-SVC.15 and not stay on the one 
included in the image.


I think this is important for everyone that has a product based on 
6.1 and that want to migrate someday to pharo7. This way it is 
impossible to do it step by step.


If there is a package .15 in the image and a package .15 in the 
repo, I think Metacello will not update because it rely on the 
numbers to know when to update. If it find a .15 and currently 
have a .15 I think Metacello will think they are at the same 
version.




Norbert







--
Cyril Ferlicot
https://ferlicot.fr <https://ferlicot.fr/>

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

I checked the Parasol Archive and it does not appear to be in Zip64 
format (Metacello uses ZipArchive which can't cope with Zip64 but 
ZipArchive can read the Parasol zip). So my next guess is that there's 
either a problem with Metacello or Pharo in the way that ZipArchive is 
used (e.g. endianness problem or non-binary stream data). It would 
therefore be helpful to find out what happens in ZipArchive>>readFrom:, 
i.e. what kind of stream is passed / opened, is it binary, does the file 
exist and is it still the correct file.


I'd debug it myself but I can't run VirtualBox at the moment because I'm 
on the macOS beta and it won't start...


Max

On 9 Jul 2018, at 18:31, Norbert Hartl wrote:


Hi Max,



Am 09.07.2018 um 18:18 schrieb Max Leske :

Hi Norbert,

This is a bit of a guess, but it's possible that the archive that is 
downloaded from github is in Zip64 format and that the libraries for 
extracting Zip64 are missing on your Linux. That would of course 
contradict the experience that the same operation appears to work in 
6.1.



to be honest I don’t know what Zip64 format is. I thought the Zip 
classes are pure smalltalk for unpacking.
Try extracting the archive manually on your Linux machine with the 
same method that Metacello uses (I assume, Metacello uses the 
ZipPlugin, which will probably use the system libraries).





I have no ZipPlugin as library in any of my vms.

But there are zips downloaded and unpacked. I start the image the 
first time loading all the code of my project. Then it is saved, 
copied to a new name and reopened to load the tests and then it fails. 
I did try to load the tests in the first run and then it works.


I’m running out of ideas

thanks,

Norbert

Cheers,
Max


On 9 Jul 2018, at 17:14, Norbert Hartl wrote:

With the help of Esteban I got one step further. If I do

MCWorkingCopy
managersForClass: ZnFileSystemUtils
do: [ :each | each ancestry initialize ]

before loading my project it updates Zinc-FileSystem as well. Sadly 
it still does not work for me because I get


Loading baseline of BaselineOfMobilityMap...
...RETRY->BaselineOfParasol
...RETRY->BaselineOfParasolError: can't find EOCD position

and I don’t know why. zip file is downloaded from github and 
present but it fails and only on my jenkins on linux. On my Mac this 
works.


I try a few things but then I’m back on pharo6.1 for the time being 
:(


Norbert


Am 07.07.2018 um 13:28 schrieb Norbert Hartl <mailto:norb...@hartl.name>>:


Really? I thought the same but then I didn’t believe it works like 
that.


Anyway this would be very easy to solve. We just need to ask Sven if 
he is fine with doing an empty .16 version for Zinc-FileSystem and 
does an in-place version reset of 2.9.2 or a new 2.9.3. I’m not 
fully convinced that will solve it but the cost won’t be very 
high.


Norbert


Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot 
mailto:cyril.ferli...@gmail.com>>:



Need to investigate more. There are two .15 versions but there is 1 
year in between (if you didn’t notice TheIntegratior.15 is from 
2017). Just want to have more context information because I can 
only see that this is strange but lacking insight.


I’m trying to figure out why it does not update Zinc-FileSystem. 
No matter what I do I cannot get Metacello to load the newer 
package. That would fix the issue because I’m loading 2.9.2 which 
should have Zinc-FileSystem-SVC.15 and not stay on the one included 
in the image.


I think this is important for everyone that has a product based on 
6.1 and that want to migrate someday to pharo7. This way it is 
impossible to do it step by step.


If there is a package .15 in the image and a package .15 in the 
repo, I think Metacello will not update because it rely on the 
numbers to know when to update. If it find a .15 and currently have 
a .15 I think Metacello will think they are at the same version.




Norbert







--
Cyril Ferlicot
https://ferlicot.fr <https://ferlicot.fr/>

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

Hi Norbert,

This is a bit of a guess, but it's possible that the archive that is 
downloaded from github is in Zip64 format and that the libraries for 
extracting Zip64 are missing on your Linux. That would of course 
contradict the experience that the same operation appears to work in 
6.1.


Try extracting the archive manually on your Linux machine with the same 
method that Metacello uses (I assume, Metacello uses the ZipPlugin, 
which will probably use the system libraries).



Cheers,
Max


On 9 Jul 2018, at 17:14, Norbert Hartl wrote:


With the help of Esteban I got one step further. If I do

MCWorkingCopy
managersForClass: ZnFileSystemUtils
do: [ :each | each ancestry initialize ]

before loading my project it updates Zinc-FileSystem as well. Sadly it 
still does not work for me because I get


Loading baseline of BaselineOfMobilityMap...
...RETRY->BaselineOfParasol
...RETRY->BaselineOfParasolError: can't find EOCD position

and I don’t know why. zip file is downloaded from github and present 
but it fails and only on my jenkins on linux. On my Mac this works.


I try a few things but then I’m back on pharo6.1 for the time being 
:(


Norbert



Am 07.07.2018 um 13:28 schrieb Norbert Hartl :

Really? I thought the same but then I didn’t believe it works like 
that.


Anyway this would be very easy to solve. We just need to ask Sven if 
he is fine with doing an empty .16 version for Zinc-FileSystem and 
does an in-place version reset of 2.9.2 or a new 2.9.3. I’m not 
fully convinced that will solve it but the cost won’t be very high.


Norbert


Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot 
mailto:cyril.ferli...@gmail.com>>:



Need to investigate more. There are two .15 versions but there is 1 
year in between (if you didn’t notice TheIntegratior.15 is from 
2017). Just want to have more context information because I can only 
see that this is strange but lacking insight.


I’m trying to figure out why it does not update Zinc-FileSystem. 
No matter what I do I cannot get Metacello to load the newer 
package. That would fix the issue because I’m loading 2.9.2 which 
should have Zinc-FileSystem-SVC.15 and not stay on the one included 
in the image.


I think this is important for everyone that has a product based on 
6.1 and that want to migrate someday to pharo7. This way it is 
impossible to do it step by step.


If there is a package .15 in the image and a package .15 in the 
repo, I think Metacello will not update because it rely on the 
numbers to know when to update. If it find a .15 and currently have 
a .15 I think Metacello will think they are at the same version.




Norbert







--
Cyril Ferlicot
https://ferlicot.fr 

Re: [Pharo-dev] Need help to get a list of Pharo projects with tests

[Max Leske]

Fuel: https://github.com/theseion/Fuel
Seaside: https://github.com/SeasideSt/Seaside

On 5 Jul 2018, at 16:31, Serge Stinckwich wrote:

On Thu, Jul 5, 2018 at 3:24 PM Julien  
wrote:



Hello Pharo community,

I am currently working on detecting rotten tests in Pharo projects.

Rotten tests are defined as test methods containing one or many 
assertions
in their source code but one or many of these assertions are not 
executed

when the test is run.
To have more details on the subject, you can check the research 
report
related to our first definition of these tests freely available on 
HAL [1].


In this context, we built a test analyser which, given a Pharo 
package
containing tests, finds rotten tests [2]. This analyser is still 
under

development.

We would like to extend the experiment of our research report [1] and 
to
analyse more projects in order to get a better understanding of 
rotten

tests.

To do that, we need your help. You can help us in two ways:
1. Answer this email with links to one or many open-source Pharo 
projects

containing tests.



​We have 774 tests in PolyMath:
https://github.com/PolyMathOrg/PolyMath

--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally 
for

machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

On 4 Jul 2018, at 23:00, Norbert Hartl wrote:


Am 04.07.2018 um 17:52 schrieb Max Leske :

Hi Norbert,

Where can I get my hands on that image that you say has no sender of 
#newBinaryFileNamed:do: in it?


I cannot give away the image, sorry. I can try to reproduce it 
somehow.

Do you expect the method to be there?


I would have, yes. But as you have discovered, the problem may lie with 
ZnFileSystemUtils (although I would have expected that package to be 
updated along with Zinc).


Max



Norbert

Max


On 4 Jul 2018, at 17:30, Norbert Hartl wrote:

I tried to see how hard it would be to load my current project in 
pharo7. Cyril helped me to see that I load an old version of zinc 
and it does not work that way. Upgrading to zinc 2.9.2 made it work 
in pharo 7 but my jenkins build do not work anymore. I don’t fully 
understand what is happening. I see in the log


Loading baseline of BaselineOfMobilityMap...
...RETRY->BaselineOfParasol
...RETRY->BaselineOfParasolMessageNotUnderstood: 
ZnFileSystemUtils class>>newBinaryFileNamed:do:
ZnFileSystemUtils class(Object)>>doesNotUnderstand: 
#newBinaryFileNamed:do:

ZnClient>>downloadEntityTo:
ZnClient>>downloadTo:
IceMetacelloPharoPlatform(MetacelloPharoPlatform)>>downloadZipArchive:to:

The strange thing about it is that when I download that image where 
the error occurred I cannot find a sender of #newBinaryFileNamed:do: 
and the #downloadEntityTo: does not seem to use it. Downgrading to 
zinc 2.8.10 makes it work again.


I feel a little bit stupid because the image does not load any new 
package on startup and still there is this error message which does 
not make sense to me at all.


Any ideas?

Norbert

Re: [Pharo-dev] Problem with zinc 2.9.2

[Max Leske]

Hi Norbert,

Where can I get my hands on that image that you say has no sender of 
#newBinaryFileNamed:do: in it?


Max

On 4 Jul 2018, at 17:30, Norbert Hartl wrote:

I tried to see how hard it would be to load my current project in 
pharo7. Cyril helped me to see that I load an old version of zinc and 
it does not work that way. Upgrading to zinc 2.9.2 made it work in 
pharo 7 but my jenkins build do not work anymore. I don’t fully 
understand what is happening. I see in the log


Loading baseline of BaselineOfMobilityMap...
...RETRY->BaselineOfParasol
...RETRY->BaselineOfParasolMessageNotUnderstood: 
ZnFileSystemUtils class>>newBinaryFileNamed:do:
ZnFileSystemUtils class(Object)>>doesNotUnderstand: 
#newBinaryFileNamed:do:

ZnClient>>downloadEntityTo:
ZnClient>>downloadTo:
IceMetacelloPharoPlatform(MetacelloPharoPlatform)>>downloadZipArchive:to:

The strange thing about it is that when I download that image where 
the error occurred I cannot find a sender of #newBinaryFileNamed:do: 
and the #downloadEntityTo: does not seem to use it. Downgrading to 
zinc 2.8.10 makes it work again.


I feel a little bit stupid because the image does not load any new 
package on startup and still there is this error message which does 
not make sense to me at all.


Any ideas?

Norbert

Re: [Pharo-dev] Fuel Error in Latest Launcher

[Max Leske]

Thanks Sean.

On 21 Jun 2018, at 18:08, Sean P. DeNigris wrote:

> Max Leske wrote
>>> Where should this bug be reported?
>>> https://github.com/theseion/Fuel/issues ?
>>
>> Yes, please.
>
> https://github.com/theseion/Fuel/issues/234
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Fuel Error in Latest Launcher

[Max Leske]

On 21 Jun 2018, at 15:34, Sean P. DeNigris wrote:


Eliot Miranda-2 wrote

Looks like the bug is that Fuel is…


Ah, glad we identified it!

Where should this bug be reported? 
https://github.com/theseion/Fuel/issues ?


Yes, please.





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

Re: [Pharo-dev] Fuel Error in Latest Launcher

[Max Leske]

Good on you!

I don't need the information for Fuel, but if you discovered a compiler 
bug it would help to post the information.


Max


On 21 Jun 2018, at 5:54, Sean P. DeNigris wrote:


Eliot Miranda-2 wrote

could you post some more information?


Hey guys, I solved my problem by recreating the blocks in question. I 
got
lucky that they were all default values, so that was easy. However, if 
the
problem is an interesting one, I can go back to the corrupt data and 
get the

info you requested…



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

Re: [Pharo-dev] Fuel Error in Latest Launcher

[Max Leske]

Hi Sean,

Is it possible that your compiled method has been corrupted? It's the 
compiler that chokes when Fuel tries to read #endPC, and the compiler 
should not choke on a well formed compiled method... (or ever for that 
matter?),



Max

On 20 Jun 2018, at 15:07, Sean P. DeNigris wrote:

While Fuel was trying to serialize a sort block ([ :a :b | a name < b 
name
]), I got CompiledMethod>>errorSubscriptBounds:. One strange thing 
about the

block is that the outerContext is `SortedCollection>>DoIt`, meaning I
probably had to initialize it by hand due to a previous Fuel problem.

The odd thing about the error is that this object graph was 
serializing and

materializing just fine before I upgraded Pharo Launcher.

Call chain:
CompiledMethod(Object)>>errorSubscriptBounds:
CompiledMethod(Object)>>at:
InstructionStream>>interpretNextV3PlusClosureInstructionFor:
OpalEncoderForV3PlusClosures class>>interpretNextInstructionFor:in:
InstructionStream>>interpretNextInstructionFor:
[ (InstructionStream new method: self pc: pc)
interpretNextInstructionFor: nil ] in
CompiledMethod(CompiledCode)>>abstractBytecodeMessageAt: in Block: [
(InstructionStream new method: self pc: pc)...
BlockClosure>>on:do:
CompiledMethod(CompiledCode)>>abstractBytecodeMessageAt:
BlockClosure>>blockCreationBytecodeMessage
BlockClosure>>endPC
BlockClosure>>abstractBytecodeMessagesDo:
BlockClosure>>isClean
BlockClosure>>shouldBeSubstitutedByCleanCopy
BlockClosure>>fuelAccept:
FLLightGeneralMapper>>mapAndTrace:



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

Re: [Pharo-dev] Why do we have SmallDictionary?

[Max Leske]

Well, I can answer my own question: SmallDictionary is a lot more space 
efficient.


I think the class comment should clarify the use case for 
SmallDictionary and mention the performance trade off.


Max

On 8 Jun 2018, at 8:46, Max Leske wrote:


Hi,

I was messing around with SmallDictionary when I suddenly realised 
that I can't find a single reason to use it over a normal Dictionary. 
While its name and class comment imply that it is somehow an optimised 
Dictionary, I don't see any measurement where that actually holds up. 
The following was run in a Pharo 7 image on a recent VM (see below):


| d |
d := SmallDictionary new.
d sizeInMemory. "24"
[10 timesRepeat: [
1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:05.226"

[10 timesRepeat: [
d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041"



| d |
d := Dictionary new.
d sizeInMemory. "16"
[10 timesRepeat: [
1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. "0:00:00:00.385"
[10 timesRepeat: [
d at: 48 ifAbsent: [] ] ] timeToRun.  "0:00:00:00.006"


As you can see, SmallDictionary is 8 bytes larger per instance and 
significantly faster while reading and writing (I know that this isn't 
a good benchmark but it suffices to make my point).



Is anyone aware of a reason for hanging on to SmallDictionary? I'm 
also curious to know how SmallDictionary came to be. There must have 
been some advantage over Dictionary at some point in the past.



Cheers,
Max





Image version: Pharo 7.0
Build information: 
Pharo-7.0+alpha.build.961.sha.a69e72a97136bc3f93831584b6efa2b1703deb84 
(32 Bit)


VM version: CoInterpreter VMMaker.oscog- nice.2281 uuid: 
4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017
StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: 
2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017
VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
$ Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $


OS: macOS 10.13.5
Machine: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Max Leske]

Hi Sean,

On 8 April 2018 at 15:33:11, Sean P. DeNigris (s...@clipperadams.com) wrote:

I was bitten by this very annoying bug again. As most of us probably know
due
to the steady stream of confused ML posts in the past, the bug in summary is

that we have an incomplete timezone implementation that doesn't properly
take into account historical DST changes. This flares up without warning
especially when DST toggles. I created a wiki page to document the
situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco

Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
'1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert:
'1/1/1901' asDate = aDate and… whammo, an exception! The "different" offsets

render equal dates unequal depending on when the objects were created.

The more I think about it, the more I think that we should just assume UTC
for all Date[AndTime]s that don't explicitly specify an offset, rather than
pretend to set an offset which is only sometimes correct. More advanced
users can use one of the available libraries to get full timezone support.
What do you think?

I first wanted to fully agree with you but then I had to think back on the
times I've had to fight timestamp bugs when working with Pharo and
relational databases. A database will make its own assumptions about the
offset. From the PostgreSQL documentation (
https://www.postgresql.org/docs/9.1/static/datatype-datetime.html):

"For timestamp with time zone, the internally stored value is always in UTC
(Universal Coordinated Time, traditionally known as Greenwich Mean Time,
GMT). An input value that has an explicit time zone specified is converted
to UTC using the appropriate offset for that time zone. If no time zone is
stated in the input string, then it is assumed to be in the time zone
indicated by the system's timezone parameter, and is converted to UTC using
the offset for the timezone zone."

Assuming UTC is probably just as wrong as assuming the local time zone.
Maybe the problem is more about the interface of DateAndTime, where you
don't really have to care about the time zone offset until it bites you. If
the interface would force you to specify the time zone, then you'd be aware
from the beginning that it's something to take into account.


Cheers,

Max





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

Re: [Pharo-dev] Build 739 breaks project load initialization order?

[Max Leske]

Great! Thanks Guille!



On 29 March 2018 at 09:49:37, Guillermo Polito (guillermopol...@gmail.com)
wrote:

PR: https://github.com/pharo-project/pharo/pull/1161

I added a test to avoid this problem in the future.

Guille

On Thu, Mar 29, 2018 at 9:36 AM, Guillermo Polito <guillermopol...@gmail.com
> wrote:

> Issue: https://pharo.manuscript.com/f/cases/21658/
> Monticello-initializers-are-not-enabled-by-default
>
> On Thu, Mar 29, 2018 at 9:33 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> I'm checking it.
>>
>> It may be a side effect of: https://github.com/pharo-proje
>> ct/pharo/pull/1130
>>
>> Short story long:
>>  - building Pharo we need to ensure that class initializations are
>> executed in a particular order, so some metacello configurations are
>> disabling monticello initializers during baselines
>>  - I introduced/refactored a couple of new baselines because I'm playing
>> with creating smaller images.
>> - I discovered (and tried to patch probably not entirely right) a bug
>> that makes baseline postloads being executed more than once
>>  - but all tests were green :D
>>
>> So I'll introduce a new test to verify that monticello initializers are
>> enabled by default and check what the problem is.
>> Keep you updated.
>>
>>
>> On Thu, Mar 29, 2018 at 9:18 AM, Max Leske <maxle...@gmail.com> wrote:
>>
>>> I can confirm that class side #initialization is broken. Don't know
>>> since when though.
>>>
>>> Cheers,
>>> Max
>>>
>>>
>>>
>>> On 29 March 2018 at 08:28:00, Martin McClure (mar...@hand2mouse.com)
>>> wrote:
>>>
>>> Good to know. In my case, however, I'm always loading code into a fresh
>>> image where these classes don't previously exist, so I would think that
>>> #initialize would always be sent.
>>>
>>>
>>> On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote:
>>> > class side #initialize is only send by MC if the incoming source code
>>> is different, has changed. I always add a date in a comment to be sure.
>>> >
>>> >> On 29 Mar 2018, at 04:47, Martin McClure <mar...@hand2mouse.com>
>>> wrote:
>>> >>
>>> >> On 03/28/2018 04:35 PM, Martin McClure wrote:
>>> >>> I have a project that loads via Metacello in builds up through build
>>> >>> 738. In 739 the load fails with DNU.
>>> >>>
>>> >>> The failure is in a method I have specified via a #postLoadDoIt:. It
>>> >>> fails because it sends a message to a pool variable, which is nil.
>>> >>> However, it should not be nil because it should have been
>>> initialized by
>>> >>> a class-side #initialize method in a prerequisite package.
>>> >>>
>>> >>> Again, this worked up through build 738. Any idea what changed in 739
>>> >>> that would cause this, and is this change intentional?
>>> >> Odd, I don't see any code changes that would be likely to have caused
>>> this.
>>> >>
>>> >> Is the expected behavior of Metacello to send #initialize to classes
>>> in
>>> >> prerequisite packages before running a #postLoadDoIt in a package? I'd
>>> >> think so, but am starting to wonder if this is perhaps unordered and
>>> >> I've just been lucky...
>>> >>
>>> >> -Martin
>>> >
>>>
>>>
>>>
>>
>>
>> --
>>
>>
>>
>> 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
>> <http://www.cnrs.fr>*
>>
>>
>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>
>> *Phone:* +33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone:* +33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



--



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
<http://www.cnrs.fr>*


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

*Phone:* +33 06 52 70 66 13

Re: [Pharo-dev] Build 739 breaks project load initialization order?

[Max Leske]

I can confirm that class side #initialization is broken. Don't know since
when though.

Cheers,
Max



On 29 March 2018 at 08:28:00, Martin McClure (mar...@hand2mouse.com) wrote:

Good to know. In my case, however, I'm always loading code into a fresh
image where these classes don't previously exist, so I would think that
#initialize would always be sent.


On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote:
> class side #initialize is only send by MC if the incoming source code is
different, has changed. I always add a date in a comment to be sure.
>
>> On 29 Mar 2018, at 04:47, Martin McClure  wrote:
>>
>> On 03/28/2018 04:35 PM, Martin McClure wrote:
>>> I have a project that loads via Metacello in builds up through build
>>> 738. In 739 the load fails with DNU.
>>>
>>> The failure is in a method I have specified via a #postLoadDoIt:. It
>>> fails because it sends a message to a pool variable, which is nil.
>>> However, it should not be nil because it should have been initialized
by
>>> a class-side #initialize method in a prerequisite package.
>>>
>>> Again, this worked up through build 738. Any idea what changed in 739
>>> that would cause this, and is this change intentional?
>> Odd, I don't see any code changes that would be likely to have caused
this.
>>
>> Is the expected behavior of Metacello to send #initialize to classes in
>> prerequisite packages before running a #postLoadDoIt in a package? I'd
>> think so, but am starting to wonder if this is perhaps unordered and
>> I've just been lucky...
>>
>> -Martin
>

Re: [Pharo-dev] Iceberg Loading issue

[Max Leske]

Hi Vincent,

Possibly a problem with updating FETCH_HEAD. Does it work when you perform
only the pull operation from Pharo (i.e., check out the branch on the
command line)?


Cheers,
Max



On 26 January 2018 at 00:43:40, vincent.blond...@lamresearch.com (
vincent.blond...@lamresearch.com) wrote:

Hi,

I am encountering some problems with Iceberg on the latest version.

I want to load the commits I just made on a branch on my Pharo fork, let's
say "21124". I set the local repo to the current version of my Pharo image,
i.e. the development branch (commit 0dbf86).
Thanks to the iceberg interface, I change the current branch to "21124",
there are 12 commits that are incoming.
Then, I then do "Pull incoming commit" to load them.
But after a few moment, instead of loading only the delta between the
development branch and the "21124" one, iceberg goes further in the commit
history and wants to load 174 commits... Including one that does not load.

By debugging, it seems that there is a problem with
LGitRepository>>fastForward:, the result of "self lookup: 'FETCH_HEAD'"
gives not the good commit i.e. the one of the development branch (commit
0dbf86), but instead the one of "I do not what".

Does this issue is known? And how can I bypass it or solve it?

Thanks,

Vincent

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

[Max Leske]

Hi Martin,

What I do is
1. update local pharo repository on branch 'development'
2. add repository to Iceberg
3. create branch for phogbugz issue
4. make changes (e.g. load stuff from your project)
5. Note that you will have to handle addition and removal of packages
separately:
5.1 addition: click 'add package'
5.2 removal: click 'remove package'. You will have to commit the removal
from the command line, as Iceberg does not currently recognize removals as
staged changes.
I usually just make a second commit with the removal before I push
everything.
6. Now the changes may not show up. But you can right click on the
repository in Iceberg and select 'Synchronize full repository'
7. Select the changes you want to commit

The rest you know, I guess ;)

Cheers,
Max



On 16 January 2018 at 20:16:22, Martin Dias (tinchod...@gmail.com) wrote:

Hi, I followed the guide and everything is good. What I don't know is how
to upgrade an external project already integrated in Pharo 7 (Epicea). I
have new version 8.2.6.

Cheers, Martín.

On Tue, Jan 9, 2018 at 11:01 AM, Sean P. DeNigris 
wrote:

> EstebanLM wrote
> >> Mmm. I think this is because your local clone is outdated.
> >> It should be fixed with a fetch… from pharo-project, I mean :)
>
> That worked. Thanks. Next problem: Iceberg is showing a massive number of
> changes when syncing with pharo fork on the dev branch at the same commit
> as
> the image. There doesn't seem to be a way to collapse the whole tree making
> it impossible to find the real changes. I assume it's that known bug where
> the first commit will sync the list, but not very user friendly!
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Fuel - FLPharo6Platform in Pharo 7

[Max Leske]

Thanks Torsten, I'll make the update tomorrow (
https://github.com/theseion/Fuel/issues/227).

Cheers
Max



On 11 January 2018 at 22:32:09, Torsten Bergmann (asta...@gmx.de) wrote:

There is a class FLPharo6Platform with


FLPharo6Platform isResponsibleForCurrentPlatform

returning false in Pharo 7 actually.

There is no comment

Do we need to care (delete, rename to FLPharo7Platform or
introduce a new FLPharo7Platform as subclass)?

Thx
T.

Re: [Pharo-dev] Hello, Im and a litle confused. Can you help me get started please?

[Max Leske]

Hi, welcome to Pharo!

This is the development list for Pharo; your question is better suited for
the users list (
http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org).
There's also a very active Discord community: http://discord.gg/Sj2rhxn.

As for documentation, there are loads of tutorials and screencasts here:
http://pharo.org/documentation.


Cheers,
Max

On 8 January 2018 at 09:55:23, Photon (nico-br...@live.de) wrote:

Hello, Folks. As is wrote in the title, I`m somewhat confused. I`m new to
programming but I think I understood what OOP is, yessterday before I
discovered Pharo, was I was able to build a simple city model in Visual
Studio (C#), with a city class which was build out of other classes wich
were build out of other classes.
City<-District<-Street<-House<-Room. So I get the idea that we want to
discribe real world systems as network of objects to be able to solve
problems within givin system.

However I have a super hard time to grasp Pharo for some reason. What I
understood so far is that everything is an object even the classes it self,
wich is super cool by the way. I understand that as I use Pharo I have to
use the libaries aswell since there is no clear cut between language and
package.
I know the browser to a slight degree and I read allready a bit code from
some objects and methods.
But then when i try to call some methods from the classes there I fail 90%
of the time.

I did not find much learning material online. Only a couple talks on Pharo
and one or two text based tutorials wich were unfortunatly pretty old,
version 1.5 or something like this.
So I really want to dig into this wonderfull subject as the concept seems
fascinating to me. I believe it can be a powerfull tool especially with the
abillity to change things runtime.

I`d be glad to get a little advice on how to start.
Cheers




-- 
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] 1.0 largeIdentityHash fails on 64-bit Linux

[Max Leske]

That seems to fix it. SmallFloat64 needs to implement #basicIdentityHash
with primitive 171. Thanks Eliot.



On 7 January 2018 at 06:19:18, Eliot Miranda (eliot.mira...@gmail.com)
wrote:

Hi Ben,

On Sat, Jan 6, 2018 at 8:47 PM, Ben Coman  wrote:

> With Linux 64 bit image
> TestRunner running FLBinaryFileStreamSerializationTest
> produces error "PrimitiveFailed: primitive #basicIdentityHash in
> SmallFloat64 failed"
>

I suspect the SmallFloat64 basicIdentityHash method is missing or using the
wrong primitive number.  Here's what happens in Squeak:

1.0 class -> 1.0 identityHash hex -> ((1.0 class
whichClassIncludesSelector: #identityHash) >> #identityHash) primitive
SmallFloat64->'16r7F0'->171

And primitive 171 is the primitiveImmediateAsInteger primitive that
converts SmallIntegers to themselves, Characters to their integer codes,
and SmallFloat64 to an integer representing their bits.  e.g.

#(-0.0 0.0 -1.0 1.0) collect: [:n| n -> n identityHash hex -> (n
identityHash bitAnd: 2 << 64 - 1) hex]
{-0.0->'-16r1000'->'16r1F000' .
  0.0->'16r0'->'16r0' .
 -1.0->'-16r810'->'16r1F7F0' .
  1.0->'16r7F0'->'16r7F0'}

SmallFloat64>>identityHash
"Answer an integer unique to the receiver."

^self primitiveFailed

HTH


> The same error occurs evaluating...
>1.0 largeIdentityHash
> which works fine on 32-bit.
>
> https://pharo.fogbugz.com/f/cases/20936/64bit-primitiveFailure-for-1-0-
> largeIdentityHash
>
> Build information:
> Pharo-7.0+alpha.build.409.sha.bb4eaaf976e3fb148b33b6d87598022b77329768
> (64 Bit)
> CoInterpreter VMMaker.oscog-eem.2295  Dec 21 2017
> StackToRegisterMappingCogit VMMaker.oscog-eem.2297 Dec 21 2017
> VM: 201712211450
> Unix built on Dec 21 2017 14:53:19 Compiler: 4.8.4
>
> cheers -ben
>



--
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] loading from github changes lgit classes?

[Max Leske]

Without taking a closer look, those are probably auto generated methods.

Max



On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com) wrote:

How come, loading a github project writes strange code change entries for
classes
like
LGitFetchOptions
LGitRemoteCallbacks
...

For example, in a Pharo 6.1 image I load bloc like this:

Metacello new
baseline: 'Bloc';
repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
load: #core

In my Epicea code change window I see this entries (see screenshot).
And the final "new" version of this classes, (class definitions) just look
like the
original class definition in a fresh image.

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

[Max Leske]

Right


On 13 September 2017 at 18:08:26, Torsten Bergmann (asta...@gmx.de) wrote:

Hi all,

as you know Denis Kudriashov does a fantastic job in implementing the new
Calypso system browser.
The plan is that at some point in time will be a replacement for Nautilus
in the standard image.
Even if not yet integrated one can already use it (either by loading from
catalog or github [1])

For me the more I use it (and get used to it) the more I like Calypso and I
guess others enjoy it too already.

But unfortunately there is a single but very prominently visible UI thing
that I dislike on the current look:

For the "Pharo3Theme" (light theme) the current implementation of Calypso
has a white toolbar in the
middle and a white status bar at the bottom. Technically Dennis sets the
colors of these morphs to
transparent to have this effect (see LEFT example of the attached
screenshot)


To me this lookes strange and unusual because
- usually (on Windows, GTK, Java Swing, Linux window managers) such areas
like a status bar follow the window color
and are displayed in gray when that is the default window theme color (see
[2], [3], [4])
- these white bars would better fit for the "Glamorous Whitespace" theme
(as this theme is already more white areas)

Also the current white bars do not make a pleasant contrast to the other
panes of Calypso:
- there is not really a visual distinction to the
package/class/protocol-tag/method panes and filters for the middle part
(toolbar)
- there is not really a visual distinction from the code pane for the
bottom part (statusbar)
- the divider line in the code pane just stops in a white area without
borders

To me this looks rather ugly and I would like Pharo to look more
professional and clean ;)

So I proposed a simple PR [5] today to change this and technically using
the window color of the theme - the result can be
seen on the right side of the attached screenshot and discussed with Denis
on Discord.

Denis on the other hand still likes the white approach on the left more
while I prefer the right one.

He wrote that he wants other people comment on this issue first to which I
agree and therefore I write this mail
to discuss it here on the dev-list and find out about what the majority in
the community prefers.

So it would be good if others could
- comment about their personal preference
- or just vote with "LEFT" (white/transparent) or "RIGHT" (window color) in
reply to this mail
- or make another proposal (which is only accepted with screenshot and PR
;)

Also please do not mix other UI discussions into this thread. Thanks in
advance!

Bye
T.

[1] https://github.com/dionisiydk/Calypso
[2]
http://cdn.osxdaily.com/wp-content/uploads/2011/08/show-status-bar-and-disk-space-lion.jpg
[3] http://i.stack.imgur.com/pgt5n.png
[4] http://python.zirael.org/gtk-statusbar1-1.png
[5] https://github.com/dionisiydk/Calypso/pull/91

Re: [Pharo-dev] Fuel Materialization Error

[Max Leske]

Hi Sean,

That cluster has been renamed. Of course, that change should be reflected
in different version numbers. Unfortunately, the version number in 6.1 is
not correct (thanks for finding that; I've logged it here:
https://pharo.fogbugz.com/f/cases/20405/Fuel-Version-number-is-incorrect-for-the-code-present-in-Pharo-6
).

Now, even though you can load 1.9.4 into Pharo 6.1 that alone will not do
you any good, as MethodContext has been renamed to Context (which is
reflected in Fuel in the changed cluster name).
>From the top of my head you would need to:
1. load Fuel 1.9.4 (i.e., load the configuration and the
"(ConfigurationOfFuel project version; '1.9.4') load")
2. load your file with a migration in which you rename "MethodContext" to
"Context" (see
https://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration)

I fear that you may run into other problems later on, but I hope this helps
at least a little.

Cheers,
Max



On 9 September 2017 at 04:28:35, Sean P. DeNigris (s...@clipperadams.com)
wrote:

I'm trying to serialize in Pharo 4.0 and materialize in Pharo 6.1. Although
both images claim Fuel 194, when materializing I'm getting: "KeyNotFound:
key #FLMethodContextCluster not found in SystemDictionary". Anyone know
what
the problem is?

Thanks!



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

Re: [Pharo-dev] poor state of fuel

[Max Leske]

Hannes,

In general it doesn't matter "how much" two images differ. What is relevant
are the changes to the graph of objects that are part of a snapshot, and
that includes changes to classes that are either part of the graph or have
instances that are part of the graph.

It is possible to reshape objects upon loading (
https://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration)
but it is certainly not automatic (some automatic migrations are possible).

One particular problem that can pop up, if you fuel out methods, are
methods who's bytecode has changed. Fuel will then stop with an error.

Cheers,
Max



On 30 August 2017 at 12:56:04, H. Hirzel (hannes.hir...@gmail.com) wrote:

On 8/30/17, Tim Mackinnon  wrote:
> Actually in my case they are similar but not identical images.

Good to know a slightly different image still can cope with a fuel
file written by another image.

Probably the results depends on which types of objects you have written.

Not sure about the influence of changes in class definitions.

--Hannes

> The Lambda image is a minimal early 7.0 one - but it is beforecthe
massive
> reworks that were announced. On top of this it has my project loaded.
>
> The OS X image is a fat 6.1 with the same project loaded. (So a
superset).
>
> I am saving the walkback context.
>
> Fuel warns that images need to be similar for it to map objects - so my
> scenario fits that (the same image would be easier I assume).
>
> Tim
>
> Sent from my iPhone

Re: [Pharo-dev] poor state of fuel

[Max Leske]

And here’s the link to the issue, for completeness:
https://github.com/theseion/Fuel/issues/224

Max



On 29 August 2017 at 16:09:06, Tim Mackinnon (tim@testit.works) wrote:

As a small data point, a fuel file written out on AWS Lambda Linux (not
sure what version - I think it's an ubuntu, but they don't really say), is
readable on OS X 64bit .

So it seems like you must have found something unusual.

Tim

Sent from my iPhone

On 29 Aug 2017, at 11:13, Max Leske <maxle...@gmail.com> wrote:

Hi Norbert,

We still maintain Fuel.

I was not aware of the problem you describe. Could you open an issue on
github (https://github.com/theseion/Fuel/issues) with a detailed
explanation and, if possible, steps to reproduce the problem?

Cheers,
Max

On 29 August 2017 at 11:04:34, Norbert Hartl (norb...@hartl.name) wrote:

I'm migrating most of my projects to pharo 6.1 at the moment. I come from
pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that
does not need to be installed and makes deployment better. That really
feels much better.

I use jenkins and there if a test fails a fuel dump is written to disk. The
jenkins server is ubuntu linux with the vm of the opensuse build. My laptop
has Mac OS and cannot read back those fuel dumps. I use the same image
version on jenkins and my laptop. Both are 64bit.

I asked that on discord and there was a mentioning that not only the 64 bit
fuel has problems. So I wanted to ask what is the state of fuel right now.
I consider fuel one of the core technologies in pharo and it is sad if it
just stops working.

Any feedback is highly appreciated,

Norbert

Re: [Pharo-dev] poor state of fuel

[Max Leske]

Thanks Tim.

Norbert, I just saw that I have already created an issue for the 64-bit
problems. I don’t know whether tackling that will help you though. In any
case, I’ll see that we try to work on those problems.

I can’t give you an exact timeline because I will be on holiday but I guess
I can make an integration by around mid September.

Cheers,
Max



On 29 August 2017 at 16:09:06, Tim Mackinnon (tim@testit.works) wrote:

As a small data point, a fuel file written out on AWS Lambda Linux (not
sure what version - I think it's an ubuntu, but they don't really say), is
readable on OS X 64bit .

So it seems like you must have found something unusual.

Tim

Sent from my iPhone

On 29 Aug 2017, at 11:13, Max Leske <maxle...@gmail.com> wrote:

Hi Norbert,

We still maintain Fuel.

I was not aware of the problem you describe. Could you open an issue on
github (https://github.com/theseion/Fuel/issues) with a detailed
explanation and, if possible, steps to reproduce the problem?

Cheers,
Max

On 29 August 2017 at 11:04:34, Norbert Hartl (norb...@hartl.name) wrote:

I'm migrating most of my projects to pharo 6.1 at the moment. I come from
pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that
does not need to be installed and makes deployment better. That really
feels much better.

I use jenkins and there if a test fails a fuel dump is written to disk. The
jenkins server is ubuntu linux with the vm of the opensuse build. My laptop
has Mac OS and cannot read back those fuel dumps. I use the same image
version on jenkins and my laptop. Both are 64bit.

I asked that on discord and there was a mentioning that not only the 64 bit
fuel has problems. So I wanted to ask what is the state of fuel right now.
I consider fuel one of the core technologies in pharo and it is sad if it
just stops working.

Any feedback is highly appreciated,

Norbert

Re: [Pharo-dev] poor state of fuel

[Max Leske]

Hi Norbert,

We still maintain Fuel.

I was not aware of the problem you describe. Could you open an issue on
github (https://github.com/theseion/Fuel/issues) with a detailed
explanation and, if possible, steps to reproduce the problem?

Cheers,
Max

On 29 August 2017 at 11:04:34, Norbert Hartl (norb...@hartl.name) wrote:

I'm migrating most of my projects to pharo 6.1 at the moment. I come from
pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that
does not need to be installed and makes deployment better. That really
feels much better.

I use jenkins and there if a test fails a fuel dump is written to disk. The
jenkins server is ubuntu linux with the vm of the opensuse build. My laptop
has Mac OS and cannot read back those fuel dumps. I use the same image
version on jenkins and my laptop. Both are 64bit.

I asked that on discord and there was a mentioning that not only the 64 bit
fuel has problems. So I wanted to ask what is the state of fuel right now.
I consider fuel one of the core technologies in pharo and it is sad if it
just stops working.

Any feedback is highly appreciated,

Norbert

Re: [Pharo-dev] Can we have subclasses of Process?

[Max Leske]

I've used subclasses of process for the debugger stuff without problems.

Max



On 17 August 2017 at 14:05:14, Denis Kudriashov (dionisi...@gmail.com)
wrote:

Hi.

Is it allowed to subclass Process?  I remember that there were some
problems with it but I could not find any information.

Generally I think about system processes which can be represented by
concrete subclasses. For example explicit UIProcess can be used to remove
many #isUIProcess conditions from system.

Best regards,
Denis

Re: [Pharo-dev] [Ann] libssh2 binding for Pharo

[Max Leske]

Very cool!


On 11 August 2017 at 16:02:55, Denis Kudriashov (dionisi...@gmail.com)
wrote:

Hi

I just want share my little experiments with libssh2. I think somebody can
be interested with it and maybe will improve what I did which is now in
very raw and initial state.

Libssh2 library is now distributed with Pharo. And it was very enticing to
try it from Pharo.
Another reason behind it is the idea to make secure transport for Seamless
and related remote tools.

So I wrapped several functions in libssh2 library. And now I am able to
send data to server using secure ssh channel. Also I can execute shell
commands on remote server from playground.

Look for details on github
https://github.com/dionisiydk/libssh2-pharo-bindings.

Best regards,
Denis

Re: [Pharo-dev] ZnEasy question

[Max Leske]

Hi Milton,

>From the URL RFC (http://tools.ietf.org/html/rfc3986, relevant grammar
attached below) it seems that 'https://' in indeed a valid path component.
ZnUrl seems to remove empty segments (which '//' would be) but that is not
correct according to the RFC (empty segments appear to be valid components
of a URL path).
An empty path segment is valid, as "path-absolute" in your case consists of
multiple "'/' segment" sequences, where "segment" is allowed to be empty.

Your should open a bug report for this.

Max



path  = path-abempty; begins with '/' or is empty
/ path-absolute   ; begins with '/' but not '//'
/ path-noscheme   ; begins with a non-colon segment
/ path-rootless   ; begins with a segment
/ path-empty  ; zero characters

  path-abempty  = *( '/' segment )
  path-absolute = '/' [ segment-nz *( '/' segment ) ]
  path-noscheme = segment-nz-nc *( '/' segment )
  path-rootless = segment-nz *( '/' segment )
  path-empty= 0

  segment   = *pchar
  segment-nz= 1*pchar
  segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / '@' )
; non-zero-length segment without any colon ':'

pchar = unreserved / pct-encoded / sub-delims / ':' / '@'
unreserved= ALPHA / DIGIT / '-' / '.' / '_' / '~'
pct-encoded   = '%' HEXDIG HEXDIG
sub-delims= '!' / '$' / '&' / ''' / '(' / ')'
/ '*' / '+' / ',' / ';' / '='

On 5 August 2017 at 03:16:16, milton mamani (akeval...@gmail.com) wrote:

Hi to all

I want to use the next instruction in my code

response := ZnEasy get: 'https://archive.softwareheritage.org/api/1/
origin/git/url/https://github.com/hylang/hy'.
response.

The previous code works from command line or in a webbrowser, but I does
not work with ZnEasy
Because it takes the previous link as:
a ZnRequest(GET /api/1/origin/git/url/https:/github.com/hylang/hy)

Could you please tell me what can I do for this situation?

Cheers,
Milton

Re: [Pharo-dev] Lots of "UTF8InvalidText: Invalid utf8 input detected" from OMBU

[Max Leske]

On 25 July 2017 at 22:55:19, Mariano Martinez Peck (marianop...@gmail.com)
wrote:

Guys,

I am getting "UTF8InvalidText: Invalid utf8 input detected" quite
frequently on Pharo 6.0 which come from ombu background job. Has anything
seen this too? Quite annoying...

Yes, I've seen it a couple of times. No clue though why it happens, or when.



This is not the first time I hit it. This time I analyzed a bit why it was
failing and it's because I removed a method manually...I mean, I did
MyClass removeSelector: #myMethod

And the omEntry is a EpMethodRemoval which represents the exact method I
deleted...

Also I can see the MultiByteFileStream internal 'collection' is full of
none ascii things.

I can share a fuelout as well as the image with the files if you want. I
can also share the ombu file in question.

Contact me in private.







[ :error |
(OmFileStoreReadingError
readingError: error
on: self fileReference
position: readStream position) signal ] in [ :readStream |
[ ^ aBlockClosure value: readStream ascii ]
on: Error
do: [ :error |
(OmFileStoreReadingError
readingError: error
on: self fileReference
position: readStream position) signal ] ] in
OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
UTF8InvalidText(Exception)>>signal
UTF8InvalidText(Exception)>>signal:
UTF8TextConverter>>errorMalformedInput
UTF8TextConverter>>nextFromStream:
MultiByteFileStream>>next
MultiByteFileStream(PositionableStream)>>match:
MultiByteFileStream(PositionableStream)>>upToAll:
OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
OmBlockFileStore>>refreshNewBlocksFrom:
[ :readStream | self refreshNewBlocksFrom: readStream ] in
OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: in
Block: [ :readStream | self refreshNewBlocksFrom: readStr...etc...
[ ^ aBlockClosure value: readStream ascii ] in [ :readStream |
[ ^ aBlockClosure value: readStream ascii ]
on: Error
do: [ :error |
(OmFileStoreReadingError
readingError: error
on: self fileReference
position: readStream position) signal ] ] in
OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^ aBlockClosure
value: readStream ascii ]
BlockClosure>>on:do:
[ :readStream |
[ ^ aBlockClosure value: readStream ascii ]
on: Error
do: [ :error |
(OmFileStoreReadingError
readingError: error
on: self fileReference
position: readStream position) signal ] ] in
OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream |
...
[ aBlock value: stream ] in
FileReference(AbstractFileReference)>>readStreamDo: in Block: [ aBlock
value: stream ]
BlockClosure>>ensure:
FileReference(AbstractFileReference)>>readStreamDo:
OmBlockFileStore(OmFileStore)>>readEntriesWith:
OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since:
[ | initialPosition initialLocalName |
self entryBuffer isEmpty
ifTrue: [ ^ self ].
fileReference
writeStreamDo: [ :fileStream |
fileStream setToEnd.
initialPosition := fileStream position.
initialLocalName := self entryBuffer first value.
ZnBufferedWriteStream
on: fileStream
do: [ :aWriteStream |
| anEntryWriter |
anEntryWriter := self newEntryWriter.
[ self entryBuffer isEmpty ]
whileFalse: [ | next entry |
next := self entryBuffer removeFirst.
entry := next key.

"Write entry to file"
anEntryWriter on: aWriteStream nextEntryPut: entry ] ].

"In Linux it was necessary to explicitely flush the file stream"
fileStream flush.
lastStreamPosition := fileStream size ].
self
refreshEntryPositionsByLocalNameStartingAt: initialPosition
since: initialLocalName ] in
OmBlockFileStore(OmFileStore)>>flushEntryBuffer in Block: [ |
initialPosition initialLocalName |...
[ caught := true.
self wait.
blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in
Block: [ caught := true
BlockClosure>>ensure:
Semaphore>>critical:
OmBlockFileStore(OmFileStore)>>critical:
OmBlockFileStore(OmFileStore)>>flushEntryBuffer
OmDeferrer>>sendMessage
[ self sendMessage ] in OmDeferrer>>flush in Block: [ self sendMessage ]




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

Re: [Pharo-dev] FileSystem file attributes and #isSymlink patch

[Max Leske]

Nice work Alistair!



On 24 July 2017 at 10:10:09, Alistair Grant (akgrant0...@gmail.com) wrote:

Hi All,

I'm nearly ready to submit a patch that started with the goal of being
able to retrieve the device id and fixing FileReference>>isSymlink and
also follows Esteban's suggestion of splitting out file existence and
other attributes (which provides a performace gain). See the summary
below for a description of the changes.

The patch involves adding a new VM plugin, FileAttriubutesPlugin. To
minimise the chance of any problems along the way I'd like to submit the
patch in three steps:

1. Add the VM plugin (FileAttributesPlugin)
2. Add the code the image that allows testing of the code and plugin,
but doesn't do any integration with existing functionality.
This will allow the plugin to be tested by a few volunteers
(hopefully).
3. Add the patches that make the switch over to the new implementation.


Can someone point me to how to submit a new VM plugin? The code is
contained in a subclass of InterpreterPlugin.

I've been using this as my production environment for about 2 months now
on a linux 32 bit VM. Running the full test suite results in the same
set of test failing before and after applying the patch.

I've also ran file related tests on linux 64 bit (run the Test Runner,
select all packages with "file" as part of the name and run all the
available tests) and the full test suite on Windows 32 bit.

The summary is:

1. #isSymlink now works properly on Linux (and it should also work on
MacOS and BSD).
2. The list of file attributes available from FileReference now is:
#accessTime (new)
#changeTime (new)
#creationTime
#deviceId (new)
#exists
#gid (new)
#inode (new)
#isBlock (new)
#isCharacter (new)
#isDirectory
#isExecutable (new)
#isFIFO (new)
#isFile
#isReadable
#isRegular (new)
#isSocket (new)
#isSymlink (works)
#isWritable
#modificationTime
#numberOfHardLinks (new)
#permissions
#size
#targetFile (new)
#uid (new)
3. FileReference>>exists is faster than before (well, at least on my
linux laptop). This is useful as it is called quite often.
4. It is possible to retrieve symbolic link attributes, e.g. all the
attributes listed above plus the target path.


Given how similar MacOS and BSD are to linux, I assume that this will
all work without problem on those platforms (but it obviously needs to
be tested).

As implied above, the changes are all backward compatible (except
the broken #isSymlink), although a couple deserve mention:

1. Obviously #isSymlink now answers correctly (previously it would only
answer correctly for a broken link).
2. Requesting any of the attributes listed above (except #isSymlink)
will return the value of the target path. If the FileReference is to a
broken symbolic link, it will return the attributes of the symbolic
link (keeping existing behaviour).
3. The attributes of a symbolic link can be retrieved using
FileReference>>symlinkAttributes.

Overall, performance is slightly better than before. Code that
needs to access multiple attributes and is written to take advantage of
the new behaviour will see significant performance improvements.


If you've got this far and forgotten the original question :-)

Can someone point me to how to submit a new VM plugin?


Thanks,
Alistair

Re: [Pharo-dev] Automatic Refactoring Disranging Seaside Rest Methods

[Max Leske]

As Gabriel notes, it looks like your missing the .sources file. I don't
know what pharocloud supports, but you could try packaging your image and
your .sources file into the same ZIP archive.

Cheers,
Max



On 18 July 2017 at 02:21:54, lionelakue (lionela...@gmail.com) wrote:

Now I can remember reading about this somewhere(wrongly remembered it as
automatic refactoring)...

I have this problem when I have to copy my image to pharocloud by example.

You need to zip your .image file and load it to the cloud.

what I am doing now is to replace my in-uri string parameters with the
excepted arg1, arg2 etc.

So is this the only solution? since the behavior is not voluntary.


gcotelli wrote
> I saw this happening only when the image cannot find the sources file, so
> it has to decompile the methods.
>
> On Mon, Jul 17, 2017 at 7:34 PM, lionelakue 

> lionelakue@

>  wrote:
>
>> Hello everyone,
>>
>> When you copy an image or sometimes when you make a Metacello commit,
>> your
>> methods are automatically refactored.
>>
>> This uncleanse the code (replacing context meaningfull variable names
>> with
>> gereric identifiers) and prevents seaside request parameters . Which are
>> mapped to method parameters by uri strings:
>>
>> ToDoHandler>>searchFor: aString
>>
> 
>>
> 
>>
>> ^ String streamContents: [ :stream |
>> ToDoList default items do: [ :each |
>> (each title includesSubString: aString)
>> ifTrue: [ stream nextPutAll: each title; crlf ] ] ]
>>
>>
>> will become:
>>
>>
>> ToDoHandler>>searchFor: arg1
>>
> 
>>
> 
>> ^ String streamContents: [ :arg2|
>> ToDoList default items do: [ :arg3|
>> (each title includesSubString: aString)
>> ifTrue: [ arg2 nextPutAll: arg3 title; crlf ] ] ]
>>
>>
>> So will end having a Parameter not found exception because arg1 and
>> aString
>> mismatche.
>>
>>
>> Is there a way to disable automatic refactoring?
>>
>> Lionel
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Automatic-Refactoring-
>> Disranging-Seaside-Rest-Methods-tp4955422.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>





-- 
View this message in context:
http://forum.world.st/Automatic-Refactoring-Disranging-Seaside-Rest-Methods-tp4955422p4955429.html
Sent from the Pharo Smalltalk Developers mailing list archive at
Nabble.com.

Re: [Pharo-dev] The new implementation of current working directory

[Max Leske]

Thanks for the detailed explanation Rajula. I think it makes perfect sense to 
separate working and image directories from each other. What you didn't mention 
is how the current working directory is resolved when an image is not started 
from the command line but by using the operating systems file browser (e.g. 
double clicking). There's also the special case of the one-click image: should 
the working directory be the image directory (which on OS X would be inside of 
the application bundle (which sucks))? Could you elaborate on that?

Cheers,
Max


> On 29 Jun 2017, at 14:42, Rajula Vineet  wrote:
> 
> Hi all,
> 
> As I have already been posting about my GSoC work and updates on my  blog
>    and on the mailing  list
> 
>  
> . In this post, I would like to go in depth of my work on 'the working
> directory'  so that I can get valuable feedback and suggestions from
> everyone. This discussion was started on an  github PR
>    which was conflicting my
> PR.
> 
> Firstly, I would like to go through the current implementation of the
> working directory. With this implementation, when you use the
> defaultWorkingDirectory method, the directory in which the running image is
> present in, is returned. This is not a completely good working because when
> you run the image from a different directory like './pharo ../Pharo.image'
> the working directory is the one in which your image resides. But that isn`t
> your actual working directory. Due to this,
> 
> 1. Pharo cannot be installed as a normal application in a read-only
> environment.
> 2. Pharo wrongly reads and writes files relative to the 'working directory'.
> 3. It also makes scripting difficult.
> 
> In the FogBugz issue  here
>   , there
> is an example which explains the problem.
> 
> Let say the Pharo VM and Image are in the directory "~/Pharo",
> and I wrote a script in "~/Documents/Pharo-scripts" called
> "perfect-numbers.st"
> 
> I have 2 possibilities:
> 
> cd ~/Pharo && pharo Pharo.image st
> ~/Documents/Pharo-scripts/perfect-numbers.st // works
> 
> or
> 
> cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st
> perfect-numbers.st // doesn't work...
> 
> It doesn't work because when pharo wants to load the file,
> it tries to locate it with: FileSystem disk workingDirectory !!!
> which is NOT the current working directory."
> 
> I hope you get the problem. 
> 
> So for the  new implementation   
> with the help of Guille I researched about $PWD and getcwd() for a while and
> wrote a new implementation. This is how it goes
> 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and
> 'getPwdFromFFIwithsize:'. These call the getcwd() function using the  UFFI
> 2. And a new method currentWorkingDirectoryPath and
> currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the
> above method and gets the working directory.
> 3. To integrate this, I have patched the DiskStore method
> 'defaultWorkingDirectory' to use the new methods in OSPlatform.
> 
> I have checked all the sendors of the 'defaultWorkingDirectory' for any
> issue. And I also wrote some unit tests. So, the new implementation is
> working fine. With this, now I am able to get the right working directory.
> The example mentioned above works perfectly. 
> 
> But, there may be a few cases where it can break interoperability between
> Pharo and other Smalltalk dialects like squeak etc.  And the 'pharo-local'
> directory and its methods should also be patched subsequently. In fact,
> these problems can be tackled by running image from its own directory itself
> (which is obvious ;) ) or by using the method imageDirectory in FileLocator
> class explicitly when necessary. But overall a good thing is this is will
> ensure the system will behave as in other languages.
> 
> I have completed this implementation and submitted a  PR
>    to github. But because of
> some dependency issue, it has not yet been merged. With the help of my
> mentor, I am working on the problem.
> 
> Thanks for reading all this. Please give your feedback and comments on this
> new implementation. Your suggestions help me in learning more about the
> project and also about the organization.
> 
> Thanks,
> Rajula
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/The-new-implementation-of-current-working-directory-tp4952918.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] WebTester project

[Max Leske]

Are you aware of the work that Johan did on Parasol 
(https://github.com/SeasideSt/Parasol )?

Max

> On 25 Jun 2017, at 16:45, Nicolas Anquetil  wrote:
> 
> 
> Hi all,
> 
> I developped a first version of a WebTestCase class.
> 
> It uses SUnit and Zinc to get pages from the internet and test some 
> conditions on them.
> 
> The main work is actually to offer higher level search facilities inspired 
> from what I saw in Selenium
> 
> There is an example, that logs in and out of Github (and checks that we 
> logged in and out)
> 
> ---
> testLoginAndOutOfGitHub
>| node |
>self defaultUrl: 'http://github.com/'.
>self getDefaultUrl.
> 
>self assert: (self searchString: 'Sign in') notNil.
>self clickLinkValue: 'Sign in'.
> 
>self assert: (self searchString: 'Sign in to GitHub') notNil.
>"5 fields to inform for login
> 3 of them have values inside the login page: commit, utf8, 
> authenticity_token"
>self enter: user forName: 'login'.
>self enter: pass forName: 'password'.
>self enterDefaultValueForName: 'commit'.
>self enterDefaultValueForName: 'utf8'.
>self enterDefaultValueForName: 'authenticity_token'.
>"bug in the page, there is a  before the real "
>node := self searchNodeTag: 'form' afterNode: (self searchNodeTag: 'form').
>self submitForm: node.
> 
>"similar for signout, submit a form with 2 default values"
>node := self searchFormOwning: (self searchString: 'Sign out').
>self enterDefaultValueForName: 'utf8'.
>self enterDefaultValueForName: 'authenticity_token'.
>self submitForm: node.
> 
>"we are out"
>self assert: (self searchString: 'Sign in') notNil.
> ---
> 
> No configOf or Catalog yet. I am too lazy
> 
> can be found at:
> 
> MCSmalltalkhubRepository
>owner: 'nicolasAnquetil'
>project: 'WebTest'
>user: ''
>password: ''
> 
> 
> nicolas
> 
> -- 
> Nicolas Anquetil -- MCF (HDR)
> Project-Team RMod
> 
> 

Re: [Pharo-dev] Seaside Control Panel crashing

[Max Leske]

Hi Casimiro,

We’re aware of the issue and already have a fix in the works. Please report 
Seaside issues to the Seaside github repository 
(https://github.com/SeasideSt/Seaside ) 
or on the Seaside mailing list.

Cheers,
Max

> On 8 Jun 2017, at 22:17, casimiro barreto  wrote:
> 
> Latest image, it crashes with 'KeyNotFound: key #NewListModel not found in 
> SystemDictionary
> 
> WAPharoServerAdapterSpecBrowser new -> WAPharoServerAdapterSpecBrowser 
> initializeWidgets -> instantiateModels: -> Array pairsDo: -> 
> WAPharoServerAdapterSpecBrowser instantiateModels -> createInstanceFor: -> 
> resolveSymbol: -> SmalltalkImage at: #NewListModel -> SystemDictionary at: 
> #NewListModel -> at:ifAbsent: -> at: [self errorKeyNotFound: #NewListModel ] 
> -> errorKeyNotFound
> 
> Nothing that cannot be solved by starting ZnServerAdaptor from workspace 
> (playground...).
> 
> -- 
> The information contained in this message is confidential and
> intended to the recipients specified in the headers. If you received
> this message by error, notify the sender immediately. The
> unauthorized use, disclosure, copy or alteration of this message
> are strictly forbidden and subjected to civil and criminal sanctions.

Re: [Pharo-dev] GitHub package management beta

[Max Leske]

Yes please!

> On 7 Jun 2017, at 03:16, Eliot Miranda  wrote:
> 
> Hi All,
> 
>I've been invited to participate in github's Bera test of their new 
> package management support.  I don't know much, if anything, about the 
> software except that it supports RubyGems (Ruby), Maven (Java) and npm 
> (JavaScript) formats.  My contact at github has asked me to supply a list of 
> email addresses of those who would like to test the software.  The contact 
> will provide documentation.
> 
> If you would like to participate please reply to me using this same subject 
> line and including in the body of the message the email you'd like used.  
> Please do top post.
> 
> Maybe we could get github to directly support Monticello.  Maybe this could 
> achieve some simplifications and ease some tensions.  I don't know.  But I'm 
> intrigued.
> 
> Cheers!
> _,,,^..^,,,_ (phone)

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

[Max Leske]

> On 4 Jun 2017, at 02:50, Cyril Ferlicot D.  wrote:
> 
> Le 04/06/2017 à 02:26, monty a écrit :
>> I've seen this before, and I'm not sure it's a bug.
>> 
>> A testless, non-abstract subclass of a TestCase is useless unless it 
>> inherits test methods. But if it defines its own test methods, then it isn't 
>> clear if it was made a subclass to inherit test methods, or if it was made a 
>> subclass to inherit non-test helper methods, or both. I think to be safe it 
>> assumes the second.
>> 
>> Implement #shouldInheritSelectors in the superclass to get your intended 
>> behavior.
>> 
>> 
> 
> I think that in most case we want the tests from the superclass. At
> least this is what I expect.
> 
> A subclass of an object keep the behaviour of its superclass when the
> methods are not overridden. Why should it be different for tests?
> 
> I see your point but if that is the case I think it should inherit the
> tests by default and we could had a way to prevent this behaviour in
> some cases.
> 
> It is very awkward to get less tests after adding a new test in a class.
> I think it reduce the power of the tests.

I second that.

> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

Re: [Pharo-dev] Iceberg ?

[Max Leske]

ls -la ~/.ssh wil probably show you that you don’t have a key named “id_rsa”. 
You have to specify the correct file (e.g. my github key is named “github”).

HTH,
Max

> On 22 May 2017, at 21:47, Stephane Ducasse  wrote:
> 
> I get
> 
> ssh-add -K ~/.ssh/id_rsa
> 
> Error connecting to agent: No such file or directory
> 
> 
> 
> 
> On Mon, May 22, 2017 at 9:46 PM, Stephane Ducasse  > wrote:
> Yes please do because I had no idea and I was trying to look at the setting 
> but without results. 
> 
> On Mon, May 22, 2017 at 8:53 PM, Esteban Lorenzano  > wrote:
> Hi, 
> 
> is not weird because git uses other authentication services and for now we 
> just implemented ssh/ssh-agent :)
> solution is to execute this in command line: 
> 
> ssh-add -K ~/.ssh/id_rsa
> 
> then it will be ok. 
> 
> (I will add an entry for this in the FAQ)
> 
> 
>> On 22 May 2017, at 20:48, Alexandre Bergel > > wrote:
>> 
>> I got the very same error. And this is weird because I can commit from the 
>> command line or using any Git client. 
>> 
>> Alexandre
>> 
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu 
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>>> On May 21, 2017, at 5:31 AM, Stephane Ducasse >> > wrote:
>>> 
>>> On mac with latest pharo vm and latest pharo 60
>>> Metacello new
>>> baseline: 'Bloc';
>>> repository: 'github://pharo-graphics/Bloc/src <>';
>>> load:#core
>>> 
>>> Then I got LGit_GIT_ERROR no ssh-agent suitable credentials found
>>> 
>>> 
>> 
> 
> 
> 

Re: [Pharo-dev] Can this regex be implemented in Pharo's one?

[Max Leske]

> On 22 May 2017, at 20:50, Mariano Martinez Peck  wrote:
> 
> Hi guys,
> 
> I have this Javascript regex to prefix CSS rules to a given ID:
> 
> css = css.replace(/([,|\}][\s$]*)([\.#]?-?[_a-zA-Z]+[_a-zA-Z0-9-]*)/g,  "$1" 
> + "#myDiv" + " $2”);

/([,|}][\s$]*)([.#]?-?[_a-zA-Z]+[_a-zA-Z0-9\-]*)


HTH,
Max

> 
> I am trying to make this work on Pharo (and then I will need in GemStone) but 
> I am getting errors while trying to create the regex itself. I am very far 
> from being a regex expert (I got that regex from StackOverflow). Any help is 
> appreciated.
> 
> Cheers,
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 

Re: [Pharo-dev] Command line save and quit

[Max Leske]

> On 17 May 2017, at 15:23, Damien Pollet <damien.pol...@gmail.com> wrote:
> 
> On 17 May 2017 at 14:34, Max Leske <maxle...@gmail.com 
> <mailto:maxle...@gmail.com>> wrote:
> >   (self hasOption: 'save')
> >   ifTrue: [ Smalltalk snapshot: true andQuit: false ].
> >   (self hasOption: 'quit')
> >   ifTrue: [ self exitSuccess ].
> 
> Yes, I think so. But you have to be careful there. Imagine that you first 
> save with "Smalltalk snapshot: true andQuit: false" and then you check for 
> 'quit' and send #exitSuccess.
> 
> But in this version the lookup for option quit is done again when the images 
> wakes up. Compare to the version originally copied by Subbu:
> 
> | quit  |
> quit := self commandLine hasOption: 'quit'.
> (self commandLine hasOption: 'save')
> ifTrue: [ Smalltalk snapshot: true andQuit: quit ].
> quit
> ifTrue: [ self exitSuccess ].
> 
> Here I'm guessing if you --save --quit then the image will get saved, and 
> next time it wakes up, enters the second conditional and #exitSuccess… 
> confusing :/

Very. When I look at this code, without going into the image and look, I would 
say that it will lead to exactly what I described: the image will start and 
exit again immediately. 

> 
> -- 
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet 
> <http://people.untyped.org/damien.pollet>

Re: [Pharo-dev] Command line save and quit

[Max Leske]

> On 17 May 2017, at 14:24, K K Subbu <kksubbu...@gmail.com> wrote:
> 
> On Wednesday 17 May 2017 05:12 PM, Max Leske wrote:
>> Yes. #exitSuccess does a bit more:
>> 1. return an exit code to the command line
>> 2. print a message
>> 3. check if the session has changed
>> 4. allows for overriding and special handling of the Exit exception.
>> 
>> You should not assume that nobody needs that :)
> 
> Thanks for the quick clarification. I am trying to understand the difference 
> between using quit and save/quit. exitSuccess never gets called when both 
> options "--save --quit" are given. Shouldn't the code handle this case as 
> well:
> 
>   (self hasOption: 'save')
>   ifTrue: [ Smalltalk snapshot: true andQuit: false ].
>   (self hasOption: 'quit')
>   ifTrue: [ self exitSuccess ].

Yes, I think so. But you have to be careful there. Imagine that you first save 
with "Smalltalk snapshot: true andQuit: false" and then you check for 'quit' 
and send #exitSuccess. What will happen after the next startup is that the 
execution will arrive at the *same point*. It will check 'quit' and exit as 
before, you will not be able to get back in to the image.
You should definitely try playing around with that, just be sure to make a copy 
of your image first :)

Cheers,
Max

> 
> Regards .. Subbu
> 

Re: [Pharo-dev] Command line save and quit

[Max Leske]

> On 17 May 2017, at 13:29, K K Subbu  wrote:
> 
> Hi,
> 
> STCommandLineHandler>>#end is defined as:
> ---
>   | quit  |
>   quit := self commandLine hasOption: 'quit'.
>   (self commandLine hasOption: 'save')
>   ifTrue: [ Smalltalk snapshot: true andQuit: quit ].
>   quit
>   ifTrue: [ self exitSuccess ].
> ---
> Can this be simplified to:
> 
>   ^Smalltalk snapshot: (self hasOption: 'save')
> andQuit:  (self hasOption: 'quit')
> 
> Is it necessary to call exitSuccess when only '--quit' is given?

Yes. #exitSuccess does a bit more:
1. return an exit code to the command line
2. print a message
3. check if the session has changed
4. allows for overriding and special handling of the Exit exception.

You should not assume that nobody needs that :)

Cheers,
Max

> 
> Regards .. Subbu
> 

Re: [Pharo-dev] Does special delay scheduler class is still needed for OSSubprocess?

[Max Leske]

Great, thanks.


> On 16 May 2017, at 17:32, Mariano Martinez Peck  wrote:
> 
> Denis, Max,
> 
> On master you can find the scheduler change rollbacked. I will soon release a 
> new version 0.2.5 but not just yet. So as for testing purpose, give it a try 
> with master. 
> 
> Cheers,
> 
> On Tue, May 16, 2017 at 10:07 AM, Mariano Martinez Peck 
> > wrote:
> 
> 
> On Tue, May 16, 2017 at 9:55 AM, Denis Kudriashov  > wrote:
> 
> 2017-05-16 14:51 GMT+02:00 Denis Kudriashov  >:
> We can do a new release with the undo of this scheduler change and give it a 
> try. What do you think?
> 
> yes, why not
> 
> But does original issue was related to itimer VM problems or not?
> 
> No
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 

Re: [Pharo-dev] Is there a way to know if I am in iTimer VM?

[Max Leske]

The --version command line option to the VM prints "ITHB" as part of the 
version for itimer VM's. Not sure whether that is accessible from within the 
image though.

Cheers,
Max

> On 16 May 2017, at 15:35, Mariano Martinez Peck  wrote:
> 
> Guys,
> 
> As you know, OSSubprocess does not work correctly in Linux unless you use the 
> iTimer VM. I would like to open a warning (that growl thingy on bottom left 
> of the screen) or something at loading / install time if I can detect I am 
> under Linux AND under traditional linux VM (not itimer).
> 
> Do you know how can I do that?  
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 

Re: [Pharo-dev] Does special delay scheduler class is still needed for OSSubprocess?

[Max Leske]

Hi Denis

Mariano is currently deciding what to do with it. See issue 
https://pharo.fogbugz.com/f/cases/20044/DelayMillisecondScheduler-leads-to-UI-lockup
 



Cheers,
Max

> On 16 May 2017, at 14:29, Denis Kudriashov  wrote:
> 
> Hi.
> 
> I found that baseline of OSSubprocess project modifies delay scheduler class.
> Is it still needed? 
> Is it related to itimer heartbeat VM issues?

Re: [Pharo-dev] Git breaks Monticello's version numbers

[Max Leske]

> On 12 May 2017, at 23:09, Oleksandr Zaytsev  wrote:
> 
> Hello
> 
> Two days ago I was trying to send the slice with my fix to PolyMath using 
> Monticello. But the version number got set to 1494471195. Today I realized 
> that all the packages to which I commit are numbered like that.
> 
> Cyril Ferlicot explained to me that this happens when I mix git and 
> Monticello commits. He suggested that I use a separate image for committing 
> to GitHub, or file out/file in if there is a lot of changes to commit.
> 
> Can this be considered a bug? Should I report it?
> 
> I think it would be causing problems for many people.

Yes, please open an issue on the GitHub issue tracker 
(https://github.com/pharo-vcs/iceberg ).

> 
> Oleks

Re: [Pharo-dev] [Zinc] How do I set the entry limit for ZnMultiValueDictionary?

[Max Leske]

> On 11 May 2017, at 14:37, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> 
> Can't you just set it to a suitable high limit then ? Like 10e6 or so ?
> 
> The limit really exists for a reason, else I would not have added it in the 
> first place.
> 
> I can't really change how dynamic variables work, and I don't feel that this 
> justifies hacking around that.

Sure, I can do that. I just thought that since there is an #unlimited 
configuration option it should be possible to use it. But I'm happy enough with 
the way it is now.

Thanks!

> 
>> On 11 May 2017, at 14:24, Max Leske <maxle...@gmail.com> wrote:
>> 
>> That's perfect, with one exception: it is still not possible to set the 
>> number of maximum dictionary entries to unlimited. In ZnMultiValueDictionary 
>> you have a nil check for the unlimited case but the dynamic variable will 
>> always default to the default value because DynamicVariable uses the default 
>> when the variable has a nil value. Not sure what the best solution is 
>> there...
>> 
>> Max
>> 
>> 
>>> On 11 May 2017, at 14:06, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>> 
>>> ZnZincServerAdaptor and subclasses expose a #server accessor that gives you 
>>> access to the configured Zn server. You should be able to grab that and set 
>>> additional options (#maximumEntitySize: #maximumNumberOfDictionaryEntries: 
>>> #defaultEncoder:) in your setup code.
>>> 
>>>> On 11 May 2017, at 14:00, Max Leske <maxle...@gmail.com> wrote:
>>>> 
>>>> Hi Sven,
>>>> 
>>>> I'm unsure about where to set the dynamic variables. I don't really want 
>>>> to do that in my WAApplication as it's not application logic. I could 
>>>> subclass ZnZincStreamingServerAdaptor... Do you have any suggestions?
>>>> 
>>>> Cheers,
>>>> Max
>>>> 
>>>> 
>>>>> On 11 May 2017, at 13:05, Max Leske <maxle...@gmail.com> wrote:
>>>>> 
>>>>>> 
>>>>>> On 11 May 2017, at 11:49, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>>>>> 
>>>>>> Hi Max,
>>>>>> 
>>>>>> First thank you for the feedback, the discussion so far and your 
>>>>>> patches. I studied them carefully.
>>>>>> 
>>>>>> Still, I decided to take another road, implementation wise.
>>>>>> 
>>>>>> You see, the reason a global setting does not make sense is that there 
>>>>>> can (and are) multiple Zn clients and servers active in the same image, 
>>>>>> and each should be independent, not be influenced by configuration 
>>>>>> changes in others. This is why the use of dynamic variables fits so well.
>>>>>> 
>>>>>> I refactored the current situation a bit and added the necessary high 
>>>>>> level hooks. I moved the default to each dynamic variable class itself, 
>>>>>> removed it from ZnConstants, and added options to both ZnClient and 
>>>>>> ZnServer.
>>>>>> 
>>>>>> Please test (code committed in bleedingEdge) and let me know if it works 
>>>>>> for you (especially then #defaultEncoder part). Maybe we have to iterate 
>>>>>> more over this to fully support your use case.
>>>>> 
>>>>> I will. Thanks Sven!
>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Sven
>>>>>> 
>>>>>> PS: One resource limit not yet moved under the new scheme is the maximum 
>>>>>> line length (currently set to 4096).
>>>>>> 
>>>>>>> On 6 May 2017, at 15:30, Max Leske <maxle...@gmail.com> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On 5 May 2017, at 17:11, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>>>>>>> 
>>>>>>>> Max,
>>>>>>>> 
>>>>>>>>> On 5 May 2017, at 16:59, Max Leske <maxle...@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> I'm performing a legal request that has more than 4000 parameters. 
>>>>>>>>> This causes the Zinc server to return 400: Bad Request because 
>>&g