[Pharo-dev] Re: [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS

[Torsten Bergmann]

Hi Pablo,

 

yes - Sven is right on that it could be improved. Thanks for taking 

care of this important topic.

Cheers,

Torsten 

 
 

Gesendet: Montag, 19. Juli 2021 um 11:46 Uhr
Von: "teso...@gmail.com" 
An: "Pharo Development List" 
Betreff: [Pharo-dev] Re: [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS


Thanks, yes it is true, the version name is a mess. 
We need to improve the version display. 
I will take note of that and I will fix it. 

 

Cheers,

Pablo


 


On Mon, Jul 19, 2021 at 11:08 AM Sven Van Caekenberghe  wrote:

Hi Pablo,

prometheus:2021-07-16 sven$ ./pharo --version
Pharo 9.0.0 built on Jul  6 2021 10:36:56 Compiler: 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.29)
Built from: ea8a3bfc - Commit: ea8a3bfc - Date: 2021-07-06 10:23:13 +0200
prometheus:2021-07-16 sven$ ./pharo Pharo.image printVersion
[version] 'Pharo9.0.0' 'Pharo-9.0.0+build.1532.sha.e58ef49051bf06cad56a2dda174b8e091a45d5df (64 Bit)'
prometheus:2021-07-16 sven$ ./pharo Pharo.image eval "(ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo"

I have said this before, but the VM version is incomprehensible for normal people, why can't it just be something like 10.1 like the rest of the world ?

Also, for mere mortals it is impossible to find out if something changed about the VM, let alone what, and how that all relates to specific versions.

I know that you guys have a lot of work, and we are very grateful for it, but this is how it looks from the outside.

Thx,

Sven

> On 19 Jul 2021, at 10:56, teso...@gmail.com wrote:
>
> Hi,
>    with the new VM I could not reproduce it. I think it was related with the issue of the NetNameResolver.
> Which VM version are you using?
>
> Thanks
>
> On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe  wrote:
> Hi,
>
> It seems that the following consistently crashes a recent/latest Pharo 9 image/vm on macOS:
>
>   (ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close.
>
> Command line, you can try it as follows:
>
>  $ ./pharo Pharo.image eval "(ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo"
>
> You can replace ZdcSocketStream by SocketStream, same result.
>
> Before, trying to connect to a non-existing host:port resulted in a ConnectionTimedOut: Cannot connect to 127.0.0.1:12335.
>
> Now, the code just returns and the bad stream is then used as if it is OK, which results in a hard crash.
>
> Furthermore, there is no backtrace nor log.
>
> Sven
>
>
> --
> Pablo Tesone.
> teso...@gmail.com

 

 
--

Pablo Tesone.
teso...@gmail.com

[Pharo-dev] Re: Can anyone get recent Pharo9 builds to work on Linux?

[Torsten Bergmann]

If you use ZeroConf (get.pharo.org) scripts be aware that

  https://get.pharo.org/64/90+vm
  https://get.pharo.org/64/90+vmLatest


will lead to the trouble with the keyboard on Linux in Playground 

and other side effects.

 

So you have to use
    https://get.pharo.org/64/vmHeadlessLatest90 (VM only) 
or https://get.pharo.org/64/90+vmHeadlessLatest (VM+image)



 
which uses latest headless VM with 90 image and this is the one working


 

Have fun,

T. (aka "astares" on Discord)

Re: [Pharo-dev] Want to run C code in Pharo using UFFI

[Torsten Bergmann]

From the filename I guess it is Windows. Should work with:

  LibC system: 'D:/DEV_FreeCAD/build/bin/box.step'

but note that .step is not a regular executable extension like EXE and other.
More a file type that is associated with the executable of free cad.

You can also check the Process class in 
https://github.com/astares/Pharo-OS-Windows
if you need more control.

For detailed questions you can meet me on Pharo Discord.

Bye
T. (aka astares)


> Gesendet: Donnerstag, 18. Juni 2020 um 08:18 Uhr
> Von: "shawon58" 
> An: pharo-dev@lists.pharo.org
> Betreff: [Pharo-dev] Want to run C code in Pharo using UFFI
>
> Hello There
> i am new to Pharo, so as i learn UFFI can handle c code, but i want to know
> that, how to run below attached code using UFFI.
>
> #include
> #include
>
> int main( void ) {
>
>   int result ;
>   result=system("D:/DEV_FreeCAD/build/bin/box.step");
>   printf("%d",result);
>   return 0;
> }
>
>
> So if anyone have idea please share with me. It will be a great help to me.
>
> Thanks for your kind help
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] #(1 1 1 2 2 2 3 3 3 4 4 4) . 3 -> #(#(1 1 1) (2 2 2) (3 3 3) #(4 4 4))

[Torsten Bergmann]

Hi Stef,
 
from the (incomplete) sample it is unclear what is really needed:
 
 1. Both return the same result: #(#(1 1 1) (2 2 2) (3 3 3) #(4 4 4))  which is 
syntactically equal to #(#(1 1 1) #(2 2 2) #(3 3 3) #(4 4 4))

    So why did you leave out the # for the contained sub-array with 2's and 3's?

 2. When the result is equal in both examples why give a different argument 
like 3 and 4? 

 3. What about edge case inputs like:   #(1 1 1 2 2 2 4 4 4)          not 
having sucessors/predecessor order
                                        #(2 2 2 1 1 1 3 3 3 4 4 4)    with 
different order (not ascending)
                                        #(1 1 1 1 2 2 2 3 3 3 4 4 4)  where 1 
is included more often than the other   

 4. ...


Nonetheless: the closest that might possibly be of use is #groupByRuns: message 


    #(1 1 1 2 2 2 3 3 3 4 4 4) groupByRuns: [:e | e ]    ->  #(#(1 1 1) #(2 2 
2) #(3 3 3) #(4 4 4))

Have fun
T.
  

Gesendet: Mittwoch, 03. Juni 2020 um 22:53 Uhr
Von: "Stéphane Ducasse" 
An: "Pharo Development List" 
Betreff: [Pharo-dev] #(1 1 1 2 2 2 3 3 3 4 4 4) . 3 -> #(#(1 1 1) (2 2 2) (3 3 
3) #(4 4 4))

Hi guys 
 
do you know if we have around a method doing the following?
 
#(1 1 1 2 2 2 3 3 3 4 4 4) . 3 -> #(#(1 1 1) (2 2 2) (3 3 3) #(4 4 4)) 
 
it could also be another one
 
#(1 1 1 2 2 2 3 3 3 4 4 4) . 4 -> #(#(1 1 1) (2 2 2) (3 3 3) #(4 4 4)) 
 
S
 


Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org[http://www.pharo.org] 
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza

Villeneuve d'Ascq 59650
France

Re: [Pharo-dev] [Pharo-users] Project of Interest => Jekyll + Dynamic processing integration + Git(hubs)Pages => pharo in the middle

[Torsten Bergmann]

Hi Cédrick,

You know  where you can quickly connect to a GitHub 
project and serve it with a global CDN easily
in seconds as in 

As the site runs HTTPS you can even host quickly a HTML/CSS/JS based PWA 
application. I tried with React and it works
nicely. So when you push a change to GitHub it easily goes live ... using two 
branches you can distinquish between prod 
vs. dev.
 

No direct need for ruby or explicit site generator - but if you need you can 
also use Pharo and try "Mustache" or "Templ" and 
similar to generate the page.
If you want Pharo for a backend or in the middle then either continue running 
your linux machine or put Pharo into docker and
run it on Azure, AWS or any other cloud based service out there. This way you 
can raise more instances when traffic raises
and you can scale. Decoupling the services is easy with REST/GraphQL and Pharo 
has projects to support that (Stargate,
Teapot/Tealight, GraphQL, ...).

You can even go serverless with Pharo Lambda Ultimate.

Many, many possibilities these days...

Have fun
T.
 
 

Gesendet: Samstag, 23. Mai 2020 um 15:13 Uhr
Von: "Cédrick Béler" 
An: "Pharo Development List" , "Any question about 
pharo is welcome" 
Betreff: [Pharo-users] Project of Interest => Jekyll + Dynamic processing 
integration + Git(hubs)Pages => pharo in the middle

Hi there, 
 
This post is just to talk about one side project I’m exploring and interested 
in from a long time. I think it may interest other people here.
 
I’d like to have powerful (static based) web site so hosting is really cheap 
(even free) and hassle free. I’ve my own server for years, it is cheap and 
simple but, of course, it needs some maintenance (linux update, nginx scripts, 
…) even if tools are the simplest I’ve found.
 
Recently thanks to student projects ;-), I found some time to learn what I find 
is a wonderful solution. This solution is to use GitHub DSCM, GitHub Pages and 
Jekyll (a ruby static site generator that is natively integrated) all together.
https://jekyllrb.com[https://jekyllrb.com] 
 
The beauty is that you can edit the site straight on GitHub. We get the power 
of version system and hosting for free… 
It literally is a CMS and the cheapest and reliable that I know of (grav might 
be another option).
 
Of course, there are some « dynamic » content possibilities too (otherwise 
GitHub Pages is enough)
- blog posts are natively generated through new files according to a name 
convention.
- there are plugins too (but you have to watch for compatibility in GitHub).
 
Dealing with forms and comments is possible
- solutions that are hosted on a third-party. Solution like Discus or 
formspree, … (that’s a NO GO to me)
- web service integration that you can host (note that form spree is on GitHub 
too 
https://github.com/formspree/formspree[https://github.com/formspree/formspree])
 
This last point is where I’d like Pharo (Zinc, Iceberg) to be integrated. Again 
we could imagine a web service system based on Zinc. I could manage form 
submissions that way and everything I’d like but it may end up complex. Do I 
need a database ? Do I need to store information and therefore manage the 
underlying architecture. If it crash, I want only the endpoint to be not 
available but the whole site still working.
 
An in between elegant solution os to use git for what it’s good at (versioning 
collaboratively through PR, and also reliable hosting in classic platforms). 
 

The idea is to use the PR mechanisms to submit stuff like blog comments (note 
that you have a free moderation system). 
This is actually not limited to comments but all kinds of possible interaction…
 
This way is (to me) better in terms of infrastructure management. Such a 
service also needs to be available (and maintained) but this is a very 
minimalist machinery (hanling POST request service only - no real content 
management as deferred to github). And again, a fail safe version (for the last 
version of the generated pages).
 
Staticman (https://staticman.net[https://staticman.net]) is a nice node 
application that allows to do this. It’s possible to host the service too.

 
I can use this node app of course, but I believe we could have quite easily 
such an application in Pharo with Zinc. 
I also wonder if we could use Iceberg to deal with this information straight in 
a pharo image (that’d be cherry on the cake). 
The super cherry of the cake would be pharo core and lib documentation, demos 
(you can have one gihub page by organization and/or users - in paid plans, you 
can have more for private stuff)… One place, one process to contribute, either 
for code or documentation.
 
Anyway, I have no real question except than asking for feedback and also to 
know if some people are interested in such project. 
 
Cheers,
 
Cédrick
 
nb: my hidden goal is to provide web site for people, unipersonal and small 
organizations. So you know, they pay for the 

Re: [Pharo-dev] Pharogenesis?

[Torsten Bergmann]

Hi Michael,

GitHub search returns two forks : https://github.com/search?q=pharogenesis

Have fun
T.

> Gesendet: Donnerstag, 14. Mai 2020 um 03:59 Uhr
> Von: "Michael Rueger" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] Pharogenesis?
>
> 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
>
>

Re: [Pharo-dev] [Mm10] 2020-03-23 (WAS: No subject)

[Torsten Bergmann]

Vincent Blondeau wrote:
>Also, what is Aleph? (I cannot find a description in this list thread...)

Hi Vincent,

see last Mm from Esteban 
(https://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2020-March/277600.html)
which says:

  "release Aleph index system to speed up big images senders/implementors and 
all Refactors associated"


It is found on

   https://github.com/estebanlm/aleph

saying "an index system for the pharo system"

Bye
T.

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

[Torsten Bergmann]

Hi Max,

thanks. I guess changes like

https://github.com/pharo-project/pharo/pull/5683

need to be reintegrated into Fuel before. Dont know if there are other.

Otherwise Release-Tests will fail during integration.

Thx
T.



> Gesendet: Montag, 09. März 2020 um 08:08 Uhr
> Von: "Max Leske" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] Updated Fuel version for Pharo 8
>
> 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
> >>
>

[Pharo-dev] Mystery solved: Pharo and Unsupported 16 bit application on Windows

[Torsten Bergmann]

Hi,

just wanted to share this story of a Windows problem + possible cause so others 
could be aware:


As Pablo announced a new VM version this week I used the VMManager within 
PharoLauncher to update the VM executables.
Unfortunately afterwards several things got broken:

When I started a fresh Pharo 9 image from Launcher the underlying Windows OS 
lamented about Pharo.exe being an "Unsupported 16 Bit application ..."
leaving me with a big question mark.


So I thought there is trouble within the new VM executable. But things got even 
more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7
VMs and images using the Launcher. Same issue here - but I was totally sure 
that it worked before without any problem.

I was not able to start ANY Pharo.exe version on this Windows machine anymore 
(except Launcher itself) - which was really mysterious. Even after
reinstalling Pharo Launcher the problem did not go away.

What I found strange was that on another second Windows machine it was working 
perfect - same combination of Launcher and any other.
So I digged deeper in finding out.


Meanwhile I know the difference:

 - on the machine where it was not working I recently installed CYGWIN toolset 
to be able to compile the Pharo VM
   that means in the PATH environment I have an "unzip.exe" in 
d:\cygwin64\bin\unzip.exe

 - I also activated the Unix subsystem for Windows (maybe that also gives a 
unzip.exe)

As PharoLauncher typically checks if an unzip.exe is available and (if found) 
it is really using it to speed things up.
Just evaluate

PhLVirtualMachineManager canUseSytemZip

in an PharoLauncher image. If it is not found it is using the regular 
"ZipArchive" class to extract - which is slower.

So it looks like when the external "unzip.exe" from Cygwin (or possibly also 
others) are found and used then the CI built ZIPs of
VM executables are not properly extracted and this leads to such effects of 
having a non-proper executable on Windows. The OS loader
then thinks it is an old unsupported 16 bit application.

Checking the version on command line for unzip exe tells me:

   UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.

When I rename that executable I found another one telling me

   GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.

A simple workaround is to enable developer mode in PharoLauncher and switching 
#canUseSytemZip to return false.
Slower - but the Pharo code is more reliable here.

Just wanted to let you know in case this problem (of which I heard several 
times already) is still on other peoples machine
still unsolved or reappearing.

Side note:
=
It is a little bit similar to what was found in 
https://github.com/pharo-project/pharo-launcher/issues/349
but a side effect of having Cygwin and other providers of unzip.exe on your 
machine in combination with Pharo(Launcher).


Have fun
T.

Re: [Pharo-dev] [Pharo-users] TaskIt

[Torsten Bergmann]

Santiago wrote:
>What if we have links to all the groups in Pharo-project (pharo-misc,
>pharo-processing, pharo-robotics, pharo-web) ? I can do the firsts steps if
>we agree in here.

Hi Santiago,

yes - we should link the groups from the main "pharo-project" so they are 
easier to find. Here are the ones I know:

1. https://github.com/pharo-project
2. https://github.com/pharo-contributions (general community managed 
contributions)
3. https://github.com/pharo-rdbms (relational database support)
4. https://github.com/pharo-nosql (NoSQL database support)
5. https://github.com/pharo-sql (points to https://github.com/pharo-rdbms)  
6. https://github.com/pharo-robotics (Robotics related)
7. https://github.com/pharo-brand (Brand Assets to do some marketing)


8. https://github.com/pharo-db (looks like offical DB stuff, but created by 
Todd Blanchard to assemble some database projects)


Not existing (yet), dont know why you need/mentioned them

https://github.com/pharo-misc  
https://github.com/pharo-processing 
https://github.com/pharo-we

For TaskIt maybe you start in "pharo-contributions" and if Pharo has more 
projects in similar directions an own separate group
could be created. 

I'm not sure if an own mailinglist other than "Pharo-users" makes sense but 
https://lists.pharo.org now also meanwhile got 
an additional "Pharo-iot" and "Workflow-engine" mailinglist. 

Thanks
T. 

Re: [Pharo-dev] BlueInk removal

[Torsten Bergmann]

To me it certainly looks like a  to get things in
by all means. Have to admit I had this kind of "panic mode" myself several 
times in the past too ;)

Stef writes he now does not have the time nor energy - which I guess (including 
his reactions) is a tribute to his workload.
But then it would have been better to change to new Elumineire or getting rid 
of GTEventRecorder in Pharo 9 and now just marking
them for later exclusion. Because often we all underestimate the depencies, 
side effects, migration costs - even the reactions.

Meanwhile Pharo is not only the base image - it is the full ecosystem around it 
which is good and a positive sign and
something we IMHO need to respect more and more.

One has to understand that by just removing and not using deprecation the 
situation is getting worse and now pulling
more time and energy from other parts of the community too. Because broken 
stuff like Spotter, Settings, Roassal, Moose, ...
would need repair
 - either directly (to help contributors who use them in P8 alpha already to 
give quick feedback)
 - together with the Pharo 8 release so they can be used
 - after Pharo 8 is released (which would be very late and might include 
migration surprises)

Depreaction would help us better managing such transitions and is something 
that is standard in other languages too.

The alternative would be to say this is OPP (other peoples problem) and 
completely ignoring that projects are built on top
of Pharo base. We all know removing leads to being incompatible and is not 
helpful in offering a transition path - therefore not
a good option. Because then users would always need to start from scratch with 
each Pharo release and loose interest quickly.

Users want to do both: use Pharo and move their projects without having to 
focus on changed infrastructure
too often. Deprecation would give more room to fixing it- we have theses 
mechanisms like deprecations and we should really use them.

In the past we were able to move more freely - but now we should really accept 
that with more users we have to
follow certain backwards compatibility and more clear rules. This slows us down 
yes and requires more time
and energy. But it is still a good thing because Pharo is actually used and the 
community can grow.

We can not move Pharo into the "perfect" future with a crowbar as this would 
mean to loose users and especially
trust into the system. We might then still come up with an improved (but still 
imperfect) system in a few years -
but nobody would be interested anymore. If we fail to see things from the POV 
of the user then we will fail overall and loose them.

I agree with Benoit that especially business users first have to solve the 
customers problems before they
can juggle with migrations. So lets support the overall community and not being 
ignorant to it.
So far we all managed it quite good: moving from Pharo 6 to 7 and even Pharo 8 
is working because things over the last
releases stabilized and also because we added more rules, depreactions, 
transformations and helping users.

I personally would prefer to see that "Pharo is not perfect but strong and 
widely used" than "look how cool it could have been",
so lets not get too impatient. Step by step - sometimes faster sometimes 
slower...

Thanks
T.

Re: [Pharo-dev] BlueInk removal

[Torsten Bergmann]

I guess most Pharo developers and user care more on RELIABILITY, STABILITY and 
REPRODUCABILITY.

Unfortunately there was

- no initial discussion on the mailinglist
- no description what "Enlumineur" is or where to find it (had to google it and 
link issue to your repo)
- PR was not reviewed nor commented from a second side although removal or 
switch to basic formatter is a more radical change
- an integrator is merging his own PR, no additional look from a second side
- all this from one day to the other
- ending up in an image broken settings and a basic formatter (who is buggy and 
eating the comments when used)
  which will also affect future contributions

We for sure all agree on the "WHY" and value that you take action to care on 
the topic. But you have to
admit the "HOW" puts a guestion mark on the way the contribution/integration 
process works.

We have broken settings now - which was clear when we just remove. This will 
also not be solved automagically
when we are past alpha stage. Especially when proper deprecation would have 
been a single method in the package
manifest, see [1].

Some community members had to repair local settings now and also this 
discussion pulls time (we all could
have better invested). If the plate is full we will not empty it out by leaving 
our paths ...

Thx
T.

[1] 
http://forum.world.st/Deprecation-guide-for-methods-classes-and-packages-td5085081.html

> Gesendet: Dienstag, 26. November 2019 um 18:29 Uhr
> Von: "ducasse" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] BlueInk removal
>
> Cyril
>
> We are crawling with too many things.
> Pharo should start to lose fat FOR REAL.
> I really hope that we will get rid of lot of old code in the future.
> If Enlumineur does not work when we integrate it - I just issue a PR
> then you will have a good case for reintegrating and having two formatter, 
> two contexts classes,
> two packages full of nearly the same but not quite tests.
>
> S.
>
> > On 26 Nov 2019, at 14:16, Cyril Ferlicot  wrote:
> >
> > On Tue, Nov 26, 2019 at 2:07 PM ducasse  wrote:
> >>
> >> Cyril can you wait until this evening?
> >> We should remove old things and having the two side by side is a lot more 
> >> painful
> >> to work.
> >> We are still in Pharo 80 alpha.
> >>
> >> Stef
> >>
> >
> > Can't we deprecate it? It's 1200 LoC, if it's deprecated everything
> > will be stricked and people will know they should not use it and it
> > will help us migrate our settings without breaking everything.
> >
> > And deprecating it is just one method in the manifest.
> >
> >>
> >>
> >
> >
> > --
> > Cyril Ferlicot
> > https://ferlicot.fr
> >
>
>
>
>

[Pharo-dev] DrTest - strange UI effect and some feedback

[Torsten Bergmann]

Hi,

DrTest is integrated into Pharo 8 now - but there seems to be a strange bug
in overlapping widgets when one uses the grouping selection box.

See attached screenshot.

I opened an issue for that: https://github.com/pharo-project/pharo/issues/5205
for Pharo. Dont know if that is known bug or even already fixed in the original 
repo
of DrTest. Would be good if the authors (Julien or Dayne) could check.

Additional feedback:

It's really a nice tool - but I see myself still switching back to old 
TestRunner again.
Two reasons:

1. Compared to the regular TestRunner where one is able to see the failing tests
   directly in DrTest one always has to have additional clicks in the
   grouping tree on the left before getting the final results.

   So the default grouping of the results as a tree could be disturbing because 
it
   requires more clicking around.

   Would be a nice addition if there would be an additional "no grouping" mode 
as well
   so the results are just shown in a list like in reglar TestRunner.

2. The old TestRunner had (after filtering the package) an additional useful 
context menu
   with "Select all" and "Select none", "Select inversion",  which allowed
   easier focusing on the test classes I want to check.
   Would be nice if a similar one could be added.

Thanks
T.

Re: [Pharo-dev] make github issues clearer?

[Torsten Bergmann]

+1000 


I've seen this several times that issues where just a short title only "wizards" were able to understand

The "Full description requires time" is not an argument here. We all should get more professional
and disciplined here - so anyone is able to reproduce and understand what an issue is about. This will
also increase the trust into Pharo and its dev process...

Bye

T.

Re: [Pharo-dev] XmlSupport on GitHub?

[Torsten Bergmann]

Hi,

Yes - this is still the current state that there only is a copy of Pharo's XML 
project available on Svens github account. 

I suggested in [1] to have a more central/official community place on 
https://github.com/pharo-contributions location 
and offered a helping hand for the migration. If I remember correctly Peter 
offered help as well.

But for the migration to GH it would be good to also know about Monty's github 
username (as I wrote in [3]) - so far there was 
NO FURTHER RESPONSE from Monty's side and therefore no further activity in 
moving XML code to github more officially.

Bye
T.

[1] http://forum.world.st/Status-of-XML-Support-s-move-to-GitHub-tt5093297.html
[2] 
https://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2019-March/274709.html
[3] 
https://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2019-March/274714.html


> Gesendet: Freitag, 04. Oktober 2019 um 12:43 Uhr
> Von: "Sven Van Caekenberghe" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] XmlSupport on GitHub?
>
> 
> 
> > On 4 Oct 2019, at 12:37, Benoît Verhaeghe  wrote:
> > 
> > Hello,
> > 
> > I think this is what you're looking for
> > https://github.com/svenvc/XML-Support-Pharo  
> > 
> > (but maybe not)
> 
> Indeed, this is just a dirty 'last-version-only' copy, definitively *not* the 
> final solutions.
> 
> > Benoît
> > 
> > Le ven. 4 oct. 2019 à 12:29, Tudor Girba  a écrit :
> > Hi,
> > 
> > Did anyone port XmlSupport to GitHub?
> > 
> > Cheers,
> > Tudor
> > 
> > 
> > --
> > feenk.com
> > 
> > “How do you feenk today?"
> > 
> > 
> 
> 
>

Re: [Pharo-dev] A call for a library to script github.com

[Torsten Bergmann]

 https://github.com/guillep/github-api
 https://github.com/astares/GitHub-API


> Gesendet: Donnerstag, 26. September 2019 um 19:01 Uhr
> Von: "ducasse" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] A call for  a library to script github.com
>
> Hi
>
> I know several people that would like to script from Pharo the github API.
>   - for the new review tools
>   - for posting bugs from pharo
>   - for dashboard
>   - for moose scripting
>
> There is also stargate and I would like to know whether there exist a library
> to build on top to script github because I think that there is need for a 
> nice lib
> for that
>
> Stef
>
>
>
>

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[Torsten Bergmann]

After some testing on two machines with "1903" Win update and loading of 
different projects with 64bit images I
can also confirm that it is working without any visible side effect. As several 
windows users confirmed I guess it can
be used in offical VM bundle, launcher, etc. now.

Super cool + Big thanks!

Bye
T.

Re: [Pharo-dev] Slot definition API?

[Torsten Bergmann]

> I will have a look, but I feel that we should first get the Composed Slots 
> into the image
> as they will change everything again.

Yes - would like to see them in as quickly as possible - but I fear they need 
more work from your side which
is time and prio related as always.
 
ComposedSlots can make things easier and allow to better control the different 
variations. 

Compositions will change how things can be composed together. But for the 
definition I guess we still
have to decide for either
 - either for the "=>" approach 
 - the plain objects approach


For compositions the => syntax would allow to just write the class name if 
there are no parameters for the slot:

  { ’someIVar' => InstanceVariableSlot + LazySlot }


But using the "just objects" approach one could would make it look like:

  { (InstanceVariableSlot named: 'someIVar') + LazySlot new }

When "+" is implemented also on instance side for composing one could even have:

 { (InstanceVariableSlot named: 'someIVar') + LazySlot }

or  { LazySlot + (InstanceVariableSlot named: 'someIVar') }
to stay symmetric.

It would also allow for:

 { ComposableSlot for: 'someIVar' using: LazySlot }"assuming that an 
InstanceVariableSlot is always in

or 

{ ComposableSlot for: 'someIVar' with: LazySlot new }   "if one uses an 
existing slot instance"

Anyhow - we can only experiment when 
https://github.com/MarcusDenker/SlotComposition moves on and 
becomes part of the image...

Bye
T.

Re: [Pharo-dev] Slot definition API?

[Torsten Bergmann]

Hi,

I'm not too deep in the CDSlotNode and related - but I wonder why we need the 
specific #=> selector and

slotName  => Definition

mapping form in the definition at all. What are the benefits of the additional 
"=>" style ?

To me it looks not very natural to write:

   #id => InstanceVariable.

or other specific forms. The custom subclasses of class "Slot" are already 
inheriting the "name" iVar for the slotName.
So using the additional slotName in the definition is

 - disrupting the slot name from other arguments
 - redundant if the slot creation should have the name as well

Why not use just the plain slot object by creating it directly with a class 
message? We can just use custom class side instantiation
methods for the slots including the name like

  #named:
  #named:type:
  #named:type:default:
   ...
or other. I mean #=> dispatches to #named: on the slot anyway.

If we define the class / slot objects like this:

   Object subclass: #MyTask
  slots: { BOInstanceVariableSlot named: #'id'.
   #anotherIVar.
   BOTypedSlot named: #'description' type: String.
   BOAttributeSlot named: #'isDone' type: Boolean default: true.
   BOAttributeSlot named: #'created' type: Date default: [ Date 
today ] }
classVariables: {  }
package: 'CustomSlots-Definitions-Examples'

is more natural than the => forms where the name is just disrupted from the 
other arguments.
The attached file out from a Pharo 8 example demonstrates this.

Just file it in and have a look at class MyTask or inspect "MyTask new created" 
 or "MyTask new created: 2"  to see that
the implemented simple slot typing and defaults are working.

Then look at the definition of #MyTask class, which looks like written above. 
It could be made even more readable using

  Object subclass: #MyTaskEvenEasier
 slots: { BOAttributeSlot named: #'id'.
  BOAttributeSlot named: #'anotherIVar'.
  BOAttributeSlot named: #'description' type: String.
  BOAttributeSlot named: #'isDone' type: Boolean default: true.
  BOAttributeSlot named: #'created' type: Date default: [ Date 
today ] }
classVariables: {  }
package: 'CustomSlots-Definitions-Examples'

only.

The benefits without the => indirection are:
 - a simple, compact and easy readable class definition even when slots are used
 - slot definitions are regular messages to the slot class - simply evaluate or 
inspect the full slot class side message
 - we keep the possibility to mix slots with other instance variables (here 
#anotherIVar in the example by using the symbol)
 - we keep the possibility to evaluate the full slots definition and check the 
array of their definition
 - we unify the definition with the "MyClass slots" message - as both are just 
return the array of slot objects
 - we do not rely on an additional specific definition API one has to remember

So where is the real value in the often used additional indirection of the  => 
message in slot definitions?

Thanks
T.


CustomSlots-Definitions.st
Description: Binary data

Re: [Pharo-dev] [Pharo-users] Pharo Branding Organization on GitHub

[Torsten Bergmann]

stepharo wrote:
> thanks for the initiative.
> I think that we have more material around, like alternate logo.
> It would be nice to collect also the svg versions?
>
> I know that lusy did also design for mugs

The SVG versions for the logo and flat-logo are in already. If you have more
then just send it around or put it in directly. I added you to the organization.

Unfortunately I do not know who lusy is ... maybe you could contact here
so we can also collect here media stuff for the repos.

Thanks
T.

Re: [Pharo-dev] About tweets

[Torsten Bergmann]

Hi Stef,

I understand - but before we focus the discussion too much on the mentioned 
#abortionismurder let's bring #4491 into perspective:

 1. Important: I guess we all agree that we would like to tweet and inform as 
much on technical topics about Smalltalk in general and
Pharo in particular and not correlate our activities to single peoples 
personal habits, politics, religion or beliefs.

 2. The aggregator that I suggested in the issue 
(https://twitter.com/WorldDotSt) is related to the website world.st - which is
a really useful technical resource on Smalltalk, Pharo and ESUG infos 
already throughout the years:

 - The forum page http://forum.world.st is summarizing various ST 
Mailinglists including ESUG list
 - https://twitter.com/WorldDotSt aggregates most of the Pharo and 
Smalltalker Tweets in existence

 3. You are referring in this thread here to the following tweet: 
https://twitter.com/AmberSmalltalk/status/1169239145530761217
which is associating @esugsmalltalk @SergeStinckwich @stephaneducasse 
#smalltalk for whatever reason with the hash tag #abortionismurder

I understand your reaction and post - but this was done outside our 
boundaries by twitter user "AmberSmalltalk" - also not by the aggregator
itself. And yes - this "AmberSmalltalk" owner seems to mix sometimes 
personal beliefs into technical infos. I share your doubts and dislike
this as well.

It's a problem that existed before and is a problem of tweeting and social 
media in general. Something that is IMHO independent from described
issue #4491 - and you and Serge definitely need to sort out this 
#abortionismurder thing with the owner of this specific account.

 4. The issue #4491 mentions that currently the Pharo community page 
(http://www.pharo.org/community)

for Twitter ONLY PROMOTES
a) the offical tweet account @pharoproject
b) your personal @stephaneducasse account
as the ones to follow.

But we have many more interesting community members tweeting on Pharo as 
you see on the list in the referred issue. So we should either
extend the community page with either more personal accounts, just use the 
offical one or use an external or own aggregator
including hashtags like #pharo, #pharoproject, ...


 5. As you might have noticed I also opened a second issue #4490 
(https://github.com/pharo-project/pharo/issues/4490) as for the blogs mentioned
on the community page we have something similar:

For Blogs WE ONLY PROMOTE on that page:
a) the official pharo weekly
b) my personal astares blog
c) the personal blog of clement

But my blog is not special either - so an aggregator of the various 
Smalltalks blogs (as the one suggested from planet smalltalk)
made initially sense to me as it would include more blogs of members of the 
community and we would not have to adopt the community page all
the time a new blog appears.

There are nice Pharo blogs out there like https://www.samadhiweb.com/blog, 
http://humane-assessment.com/blog and many other.

Same applies here: either we just include the offical blog that we control, 
a list of more blogs of the various members or an aggregator

 6. Yes - the community is unable to control what people write on Twitter, 
Blogs or other social media. Even our mailinglist "pharo-users_lists"
is not free from personal habits as yesterdays disussion about "guns" 
showed.

(http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044168.html)

And maybe linking to these aggregators or promoting them is not a good 
idea. If we take the discussion (over)serious we should then
really only link to official twitter account and official pharo blog that 
the community can control.

In such a case we need to remove my blog and your personal twitter account 
from the community page as you sometimes tweet about
politics on your personal account too and I can potentially write on other 
non-technical topics on my blog as well (which I do not plan).


Basically we have four options:
  a) we only link to the official twitter account 
(https://twitter.com/pharoproject) and blog (https://pharoweekly.wordpress.com/)
  b) extend the list with personal twitter accounts as mentioned in issue #4491 
and blogs like mentioned in #4490
  c) Link and rely on external aggregators
  d) Setup an own aggregator on sources we trust

Maybe as a valid solution an official "disclaimer" could help - that opinions 
shared on these PROMOTED sources are not controlled by
us and do not necessarily reflect the opinion of the Pharo community

And yes - the board should discuss, check and decide what to put or link to 
from the community page.

Thanks
T.

> Gesendet: Donnerstag, 05. September 2019 um 08:03 Uhr
> Von: "ducasse" 
> An: "Pharo Development List" 
> Cc: "The Pharo Project" 
> Betreff: [Pharo-dev] About tweets
>
> Hi guys
>
> I encourage everybody to 

[Pharo-dev] Pharo Branding Organization on GitHub

[Torsten Bergmann]

Hi,

the Pharo community is growing and our lovely Pharo system is an innovation 
driver with cool tools and projects 
but it is also used in real projects in research and business setups.

There are still many entries left on all our TODO lists - not only in shaping 
the next stable Pharo release(s) 
but also in bringing more attention to people about what Pharo is all about.

A few of us already follow a well know marketing phrase: “Do good and talk 
about it!” as some report about Pharo news
in BLOGS, on TWITTER or by writing articles on MEDIUM.com or even books. I also 
like that we have a growing number
of YOUTUBE videos about Pharo. We also have a regular Newsletter - even a 
Facebook page, ...

This gives visibility to Pharo activities and is already a good step in doing 
some advertising.

An additional important lesson in successful marketing is that one has to give 
a homogenous "Brand Identity" to a project or product
to be easily recognizable and rememberable over time. We already have the nice 
lighthouse and use it all over - but often it 
is hard to find the logo or other marketing material in correct size or correct 
graphics format. We should improve on that side
too.

As we work mostly with git I therefore now have setup a new organization 
"pharo-brand":

   https://github.com/pharo-brand

that should give easy access and group existing branding material in one place.

The site now already includes the following three projects:

   1. pharo-brand-material
  
  This should be the place for "logo" and "logo-flat". In the 
subdirectories you will find the logo in three different
  variations:

 - logo composed of text + icon + beacon
 - logo composed of icon + beacon
 - logo beacon only
  
   including subdirectories for "vector" (like SVG, PDF) and "screen" 
formats (like PNG, BMP, ...)

   2. pharo-github-images

  These are the Icons i created for the various github organizations like

 - https://github.com/pharo-project
 - https://github.com/pharo-nosql
 - https://github.com/pharo-rdbms
 - https://github.com/pharo-contributions
 - https://github.com/pharo-brand

  and a template for additional ones 

   3. pharo-jingle

 A jingle is a short song or tune used in advertising. Jingles are a form 
of sound and or video branding - when you see it often
 as an intro or outro you will more easily remember the brand name (Pharo 
in this case).

 This repository includes a "Pharo jingle" that can be used as a start or 
end section within own custom videos about Pharo and 
 related projects.

 The short video jingle was created using a free video software called 
OpenShot using a sound jingle from freesound.org

 - Pharo_HDV720_24p_1280x720.mp4
 - Pharo_HDV1080_25p_1920x1080.mp4
 - Pharo_HDV1440_25p_1440x1080.mp4

 Note that the jingle is currently a proposal - if you have better ones we 
can discuss it within the community on the mailinglist.


I hope the repos will improve a little bit the situation in finding and 
organizing the brand material.
Feel free to comment and give feedback or even add marketing material 
(templates, icons or other) yourself to the repos.

Thanks
T.

Re: [Pharo-dev] [Pharo-users] Information on Spec development

[Torsten Bergmann]

Cyril wrote
> Until now, the T is before the prefix. (For example TIceXXX for
> Iceberg). So I followed what was already done.

But then IMHO Iceberg is wrong too and do not correctly and consistently use 
their own prefix
in front of classes/traits.

See other samples like traits in which are also there already:

Epicea   -> EpTEventVisitor
Fuel -> FLTGlobalClassOrTraitSerializationTest
Glamour  -> GLMTBlockTags
Moose Algos  -> MalTEdgeNode
...

and where "prefix" is first as it should be.

There are several reasons why "prefix" should be first:

 1. As the name says: it is a prefix - so it would be obvious to have it in 
front of the class or trait name.

 2. Prefixes are a workaround because we do not have namespaces (yet). 
Following the "prefix" always
first rule we could later have a separation into namespaces more easily 
later when migrating.

 3. If someone uses a prefix starting with a "T" too, like "TPL" for Template 
library then
people get easily confused with class/trait mix of "TTPL" and "TPLT" 
looking like a typo or
thinking all are traits because "T" is the first.

Therefore
 - Prefix should be two (as in Seaside), ideally three letters and ideally in 
uppercase
   IMHO we should define a rule to have three uppercase letters at least for 
the base image.
 - order should be "prefix" and then class or trait name (where trait names 
start with "T".

Smalltalk provides lots of freedom. But without rules and discipline it easily
ends up in inconsistencies, chaos, a mess...

Looks like even Pharo engineers miss a code guide these days ...

Bye
T.

Re: [Pharo-dev] [Pharo-users] Information on Spec development

[Torsten Bergmann]

Cyril Ferlicot wrote:
>The revert of changes of Spec 1 is now done in Pharo 8.

Nice - lots of work. Thanks!!!

> All classes of Spec2 start with the Sp or TSp prefix.

Maybe I'm wrong but:

If "Sp" is the prefix for Spec2 and trait names start with "T" we should
used SpT... for traits, no?

Otherwise it would not be a prefix ...

Thanks
T.

Re: [Pharo-dev] [ANN] Pharo Harbour

[Torsten Bergmann]

Hi Clément,

yes - having a better FileBrowser and a FileDialog closer together makes sense.

You can freely use the code / project or reuse it for other implementation.
Thats why I opened the repo to public. Unfortunately no time to work on it 
or help the next weeks.

Bye
Torsten


> Gesendet: Donnerstag, 01. August 2019 um 10:17 Uhr
> Von: "CafeKrem" 
> An: pharo-dev@lists.pharo.org
> Betreff: Re: [Pharo-dev] [ANN] Pharo Harbour
>
> Hello Torsten,
> 
> It's Clément, actually, I'm working on the FileDialog ( of Peter ) so I will
> merge your FileBrowser with my FileDialog.
> 
> Thanks.
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 
>

[Pharo-dev] [ANN] Pharo Harbour

[Torsten Bergmann]

Hi,

I experimented with Spec on P8 to build a simple file browser.

   Metacello new
repository: 'github://astares/Pharo-Harbour/src';
baseline: 'Harbour';
load

Not much and not complete - unfortunately I had no time to test
or verify it yet and time to continue on it is limited next weeks.
But I opened the repo to be public already so others can have a look.

Use at your own risk and if you have improvements or fixes feel free
to send PR's. Maybe we can build something better to replace the old
file tool...

Bye
T.

Re: [Pharo-dev] A small game: do one trivial improvement every day

[Torsten Bergmann]

Hey YOU, YES YOU !

it was in 2017 when I asked people here on this list to help cleaning and raise 
the quality level of our Pharo system:
http://forum.world.st/Pharo-Quality-raising-the-quality-level-in-Pharo-7-and-onwards-tp5027111.html

I not only talked. I took action - meanwhile with around 658 (!) sometimes very 
trivial changes to
get Pharo 7 and 8 into a cleaner state 
(https://github.com/astares/pharo/branches)

One step at a time ... evening per evening, week per week. Sometimes there was 
a minute - sometimes not.

And yes: Pharo already became cleaner with small contributions from my and many 
others contributors side. Pharo now
already feels a little bit better - has class and test comments, more aligned 
packages, fixed categories,
less typos, cleaner and more understandable code and more rules to hopefully 
keep that quality level.


What if YOU, YES YOU would also step in and also apply simple or complex fixes 
and cleanups on internal
and also external packages? You could also help with documentation or feedback 
on what is working and what not.

If we all clean the house TOGETHER the next guest would feel already more 
comfortable and also try not to
wear his dirty shoes...

I also intentionally opened one single trivial issue without fixing it myself. 
Now today this issue got somehow
"famous" on Twitter:  
https://twitter.com/marcusdenker/status/1148287564937400321

and YOU can get famous for FIXING or REVIEWING this single issue too.

Or you can help with many others that are left either here: 
https://github.com/orgs/pharo-project/projects/8
or here: https://github.com/pharo-project/pharo/issues

Jump in - the water is just fine!

Bye
Torsten (aka "astares" on Discord)

Re: [Pharo-dev] [ANN] OSWinSubprocess a library to spawn Windows System processes

[Torsten Bergmann]

Without having a deeper look I guess what was done for Windows now is wrapping 
the usual STARTUPINFO, CreateProcess()
functions and friends yet again ...


Such wrappers and many other native friends were created from my side already 
years ago with my "OS-XXX" series
of projects for different platforms:

 - http://smalltalkhub.com/#!/~OS/OS-Windows
 - http://smalltalkhub.com/#!/~OS/OS-OSX
 - http://smalltalkhub.com/#!/~OS/OS-Unix
 - http://smalltalkhub.com/#!/~OS/OS-Linux-CentOS
 - http://smalltalkhub.com/#!/~OS/OS-Linux-Ubuntu
 - http://smalltalkhub.com/#!/~OS/OS-Raspbian

So for instance on Windows you could easily use

   WinProcess createProcess: 'explorer.exe'

or

   WinProcess createAndWaitForProcess: 'cmd.exe'.

The projects are available on Github now since 2018 and kept up to date for 
recent Pharo versions.

 - https://github.com/astares/Pharo-OS-Windows
 - https://github.com/astares/Pharo-OS-OSX
 - https://github.com/astares/Pharo-OS-Unix
 - https://github.com/astares/Pharo-OS-Linux-Ubuntu
 - https://github.com/astares/Pharo-OS-Raspbian

All of them are available in Catalog.

I have no problem with more and more implementations and the double efforts. 
But for Pharo users I have the feeling
that it gets more and more confusing in the area of OSProcess, OSSubProcess, 
OSWinSubprocess,  and more wrappers
for basically the same thing ...

Bye
Torsten (aka astares)

[Pharo-dev] Additional Divider in Pharo menu

[Torsten Bergmann]

Hi,

around 20 days ago the order of menu items in the Pharo world menu were munged 
up in the standard Pharo 8
image for whatever reasons. "Safe" was on first position and not grouped with 
other "Save ..." items anymore as it was
in the past. This was noted by Alexandre Bergel and others on Discord.

I fixed the order in the following PULL REQUEST 
https://github.com/pharo-project/pharo/pull/3529
with the menu ending up looking like this:

  !
  ! SETTINGS
  !
  ! SAVE
  ! SAVE AS
  ! SAVE AND QUIT
  !
  ! QUIT
  !

having added by intention an additional divider between
 - the more safe options to store the image (secure)
 - the unsafe quit where one can loose changes in the image (insecure if you 
just quit)

I know that "SAVE AND QUIT" and "QUIT" also might belong somehow together as 
both exit the image
- but  the diver should separate the more secure options from the more insecure 
options.


Now today the divider was removed again using 
https://github.com/pharo-project/pharo/pull/3738
from Cyril Ferlicot mentioning it as "unwanted" - so now the menu looks like 
this:

  !
  ! SETTINGS
  !
  ! SAVE
  ! SAVE AS
  ! SAVE AND QUIT
  ! QUIT
  !

as it was back in Pharo 7.

As I'm someone who is mousing around very quickly in the past it often happened 
to me that while I wanted to
really "SAVE AND QUIT" I hit accidentally the "QUIT" button directly below - 
leaving me in a state where I had
to recover or reapplying changes afterwards.

So using the additonal divider between the three "safe my data" options and the 
"just leave" was intentional and to
me makes some sense: from the point of view of grouping, visually and from 
clicking behavior.

I guess Cyril Ferlicot wanted to restore how it looked in Pharo 7 or had other 
reasons why he prefers the menu to
look like in the second picture.

I know it is not a big thing - but nonetheless: It would be good if others 
could write which option

  a) WITH DIVIDER (as in first picture to separate safe from unsafe options) or
  b) WITHOUT DIVIDER (as in second picture to stay like it was back in Pharo 7)

they really prefer so we can decide on a community / voters base.

Thx and sorry for the ASCII art
T.

[Pharo-dev] Status Pharo and PI / ARM

[Torsten Bergmann]

Back in 2015 I played with Pharo and the PI and wrote an article on Medium 
about the installation [1].
Today we have new IoT projects like PharoThings [2] and my understanding is 
that latest ARM VM is
available on [3].

But PI and ARM Support is nowhere mentioned on the pharo.org Website. ARM and 
PI Support is also not
mentioned in the Download section http://www.pharo.org/download


1. What is the status of the ARM port? Is my assumption correct that it is 
already built using CI and
   receiving latest VM code changes too?

2. Should it be mentioned already on the Pharo Download page? If so who can add 
it?

3. Is it already included into ZeroConf so one can easily grab VM+image on a 
raspbian system
   using commandline?

4. Can we use a recent image like Pharo 7 and Pharo 8 on the PI?

5. Is it possible to remotely access a Pharo image running on PI via TelePharo?
   Is there an updated RFB package for Pharo 7/8 to also use the image via 
VNCViewer

Thanks for an update...

Bye
T.

[1] https://medium.com/concerning-pharo/pharo-pi-9eef257b6a21
[2] https://github.com/pharo-iot/PharoThings
[3] http://files.pharo.org/vm/pharo-spur32/linux/armv6/

Re: [Pharo-dev] [Pharo 8.0] Build #314: Pharo8.0-ffi

[Torsten Bergmann]

On UBUNTU and on Windows I have a crash when (using a recent Pharo 8 image, 64 
bit) and running the following
scenario:

 - Open Iceberg
 - click on "Add"
 - select "Clone from GitHub"
 - use "astares" as Owner name and "pharo" as Project name, select "HTTPS" as 
Protocol, click on "Accept"

Pharo tries to clone the repo - but then the Pharo process just dies.

On Ubuntu the consol tells:

  free(): invalid pointer
  ./pharo-ui: line 11:  3604 Aborted (core dumped) 
"$DIR"/"pharo-vm/pharo" "$@"


I guess it is related to the below changes.

Bye
T.

> Gesendet: Mittwoch, 05. Juni 2019 um 18:20 Uhr
> Von: ci-pharo-ci-jenki...@inria.fr
> An: pharo-dev@lists.pharo.org
> Betreff: [Pharo-dev] [Pharo 8.0] Build #314: Pharo8.0-ffi
>
> There is a new Pharo build available!
>
> The status of the build #314 was: SUCCESS.
>
> The Pull Request #3136 was integrated: "Pharo8.0-ffi"
> Pull request url: https://github.com/pharo-project/pharo/pull/3136
>
> Issue Url: https://github.com/pharo-project/pharo/issues/Pharo8.0
> Build Url: 
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/314/
>

[Pharo-dev] Ring renaming in P8, Manifests and deprecations

[Torsten Bergmann]

Hi,

just to let you know:

If one develops a project in Pharo 7 (or before) including  a manifest with 
banned rules this may lead to
trouble in upcoming Pharo 8.

Within the manifest you will find methods referencing "RGPackage" class:

  "code-critics"
  ruleRBLiteralArrayContainsCommaRuleV1FalsePositive
^ #(#(#(#RGPackage #(#'Funny-App')) 
#'2019-06-02T17:05:15.359384+02:00') )


If you load the code into latest Pharo 8 it is not possible to browse the 
manifest class in Calypso without errors
as RGPackage class is missing in Pharo 8.

This goes back to a PR from Pavel: 
https://github.com/pharo-project/pharo/pull/3226 to consolidate and
rename RGPackage into RGPackageDefinition.
I support the PR - but not the way how it is done as it does not consider 
keeping and deprecating the old RGPackage
class.

For sure one can easily adopt the Manifest methods by replacing #RGPackage with 
#RGPackageDefinition - but be aware
that accidentially or not we add more and more burden especially to new users 
and future migrators.

IMHO we should "deprecate" and keep classes around at least one pharo version 
iteration whenever possible.
(see also the deprecation guide 
http://forum.world.st/Deprecation-guide-for-methods-classes-and-packages-td5085081.html)

We could have RGPackageDefinition as the new class, and keep the old class 
RGPackage as a subclass of RGPackageDefinition
in a "Deprecated80" package so we can easily remove it with the start of the P9 
iteration.

I also wonder why we still have the "Deprecated70" package around in latest P8 
image and why we do not remove it as usual
and just start a fresh "Deprecated80" package. It was a simple scheme and 
worked in the past without much hazzle.
Last time this was asked there was a discussions about a possible migration 
tool - but so far without any visible progress
to my knowledge. Even if such a tool exists it could use the "Deprecated70" 
package even after removal by just loading it...

Thanks
T.

Re: [Pharo-dev] [Ann] Lifeware, Schmidt Pro contracts for the consortium

[Torsten Bergmann]

Great - big thanks to all who made that possible and who support Pharo either via funding

or contributions.

 

Location of slides is https://www.slideshare.net/pharoproject/pharo-70-and-80-alpha


Bye

T.

 

Gesendet: Montag, 20. Mai 2019 um 08:03 Uhr
Von: "ducasse" 
An: "Any question about pharo is welcome" , "Pharo Development List" 
Betreff: [Pharo-dev] [Ann] Lifeware, Schmidt Pro contracts for the consortium



The Pharo consortium is very excited and super happy to bring your attention to the following announce

that was presented during Pharodays 2019: https://fr.slideshare.net/pharoproject/

 
The consortium got two contracts to support financially one year of engineer to improve Pharo.

The companies Lifeware and Schmidt Pro fund work on Pharo to improve Pharo. The total amount 

of the two contracts is around 190 K Euros. 

In addition the RMOD team got some resources from Inria. 

The net result is that in 2019 the consortium will have 3.5 engineers working full time on Pharo.

 

- Esteban Lorenzano 

- Pablo Tesone

- Cyril Ferlicot

- Guillermo Polito

 

It will boost Pharo. Note that the issues raised by Schmidt Pro and Lifeware 

and their impacts on the roadmap of Pharo 8 and Pharo 9 are presented in https://fr.slideshare.net/pharoproject/.

 

What is key to notice is that the consortium is working because many contributing companies are sharing ressources. 

This is built a strong soil to grow Pharo and business around. 

 

On the behalf of Inria, the consortium and the community we would like to thank 

Lifeware and SchmidtPro for their strong support. 

 

Stef on the behalf of the Pharo consortium

Re: [Pharo-dev] Handling of deprecation packages

[Torsten Bergmann]

Hi Stef,

It's not a big problem. I primary wanted to ask what is the status and overall 
plan.

The problem with the new vs. old streams seems to be that migration is 
unfinished even for the base image.
Development already switched quickly to newer construction sites instead of 
finishing these old ones.
That does not mean that I do not appreciate the new journeys Pharo 8 will bring 
- but it still gives this
bad feeling of important transitions are incomplete and should have been 
addressed first.

That's why also "Deprecated70" could not easily get removed. And there is no 
guide in how to migrate to the new stream.
At least I do not know of something that could quickly explain on how to 
convert.

If we integrate a "Deprecated80" (which I think we should do to continue 
deprecating stuff like required
for issue #3186) it could easily lead to confusion when we have two deprecated 
packages.

For "Deprecated70" and "Deprecated80" it might be clear from the name but as 
for P7 there were also
deprecations for other packages like "Ring-Deprecated*" it might not be clear 
over time when and how
they were deprecated.

The previous scheme we used to directly remove old deprecations when a new 
Pharo release iteration started
was at least more clear and I think it helped people to better sort out what 
and when to stop using stuff.

Bye
T.


> Gesendet: Donnerstag, 18. April 2019 um 08:26 Uhr
> Von: "ducasse" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] Handling of deprecation packages
>
> Hi torsten
>
> I do not remember if I migrated deprecated70 to the migrator package.
> I should check but if someone else wants to have a look even better.
> Then my thought was that the streams are important and making the live of 
> people easier to migrate
> important too especially since we cannot fully automate Stream deprecation.
>
> Now I would like to understand why this is so a problem for you?
>
> Stef
>
> > On 17 Apr 2019, at 23:15, Torsten Bergmann  wrote:
> >
> > Hi,
> >
> > in the past after each release iteration one of the first things applied to 
> > a new development image
> > - was to remove the "DeprecatedXX" package of the previous version XX
> > - and add a new "DeprecatedYY" package for the new pharo version YY
> >
> > This allowed then to mark classes that should get obsolete for version YY 
> > and put them into "DeprecatedYY"
> >
> > But in current Pharo 8 dev image we still have the "Deprecated70" package 
> > inside and a new "Deprecated80"
> > is not yet opened.
> >
> > I know there
> > - were some discussion about having a "migrator" tool first to help in the 
> > transition to the new release
> >   (but I guess this "migrator" could be written using P7 image, no?)
> >
> > - we can also not just delete "Deprecated70" as StandardFileStream, 
> > MultiByteFileStream and others are
> >   still useds in the code without giving a proper
> >
> > So I wonder what is the status and on plan this in P8
> >
> > Thx
> > T.
> >
>
>
>
>

[Pharo-dev] Handling of deprecation packages

[Torsten Bergmann]

Hi,

in the past after each release iteration one of the first things applied to a 
new development image
 - was to remove the "DeprecatedXX" package of the previous version XX
 - and add a new "DeprecatedYY" package for the new pharo version YY

This allowed then to mark classes that should get obsolete for version YY and 
put them into "DeprecatedYY"

But in current Pharo 8 dev image we still have the "Deprecated70" package 
inside and a new "Deprecated80"
is not yet opened.

I know there
 - were some discussion about having a "migrator" tool first to help in the 
transition to the new release
   (but I guess this "migrator" could be written using P7 image, no?)

 - we can also not just delete "Deprecated70" as StandardFileStream, 
MultiByteFileStream and others are
   still useds in the code without giving a proper

So I wonder what is the status and on plan this in P8

Thx
T.

Re: [Pharo-dev] IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows

[Torsten Bergmann]

If one downloads images with Launcher on Windows and accepts default names like 
"Pharo 7.0 - 32bit (stable)" this will end up in path names like

   "C:/Users/Admin/Documents/Pharo/images/Pharo 7.0 - 32bit (stable)"

The dot and space combination in such files can later make trouble when 
downloading projects (like Seaside) using Iceberg and libgit and leading
later to the  "IceGenericError: failed to stat file  ... The filename or 
extension is too long" problem.

I guess the dot in combination with spaces in the name is sometimes seen as the 
path element on current directory.

If one gives an own name like "LatestPharo7" in Launcher (having 
C:/Users/Admin/Documents/Pharo/images/LatestPharo7 then) Seaside loads
even from the FileTree format.


As many people prefer to use Launcher now these days they might easily hit this 
problem.

I opened an issue already for Launcher so this discussion here on ML is watched:
https://github.com/pharo-project/pharo-launcher/issues/327

Feedback and tests from Windows users are welcomed.

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

[Torsten Bergmann]

Attila wrote:
>why don't we reinitialize them before running the test?

SUnit does - but requires it to be in #setUp. One just has to follow the SUnit 
framework rules.

So if one implements

   MyTest>>initialize
   super initialize.
   s := OrderedCollection new. "note that this is initialized here not in 
the setUp as we normally do"

then this is not the problem or werd behavior of BabyMock, SUnit or Pharo.

It is a problem of the Test class (and of the one who implemented a test like 
this) as the developer did then not follow Sunit
framework rules and best practice patterns.


If you look into Simple Smalltalk Testing: With Patterns from Kent Beck (see 
http://swing.fit.cvut.cz/projects/stx/doc/online/english/tools/misc/testfram.htm)
it clearly says: "Override setUp to initialize the variables"


Design a test fixture.
 - Subclass TestCase
 - Add an instance variable for each known object in the fixture
 - Override setUp to initialize the variables


One just have to stick to the rules - if not then for sure you might run into 
side effects or weird behavior.


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

Yes - I also wonder why you use #initialize instead of #setUp in a test? Also 
the expectation for someone to read or check
a test would be to look in #setUp, not in #initialize because of the SUnit 
standards.


So it is the way SUnit was defined, works and always worked (even unit testing 
in non Smalltalk solutions):

 - #setUp
 1. setup all nececessary thing BEFORE running or rerunning a test
 2. as test's could inherit from other (base) tests the #setUp method 
should always start with a "super setUp" call
 - #tearDown
 3. cleanup after running each test case
 4. as test's could inherit from each other and resources might need to be 
freed in reverse order (compared to allocation in #setup)
the #tearDown should always end with a "super tearDown" call

I invested lot of time last year to clean up also tests for Pharo 7:
 - to follow SUnit standard
 - to introduce two new ruls (ShouldSendSuperSetUpAsFirstMessage and 
ShouldSendSuperTearDownAsLastMessage) so developers can see when they violate 
2. or 3.
 - introduced a release test to keep this quality level (see 
"ProperlyImplementedSUnitClassesTest" checking for alignment with 2. and 3. for
   all tests in our base image)

All our tests follow this standard and use #setUp and if you now check using

TestCase allSubclasses select: [:each |
each methodDictionary keys includes: #initialize
]

the only test who uses #initialize is TimeMeasuringTest but for the sole reason 
to provide the possibility to measure time when debugging.
Which is fine and no violation of the definition and rules.

Bye
T.

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

[Torsten Bergmann]

Stef wrote:
> > Note that Peter seem to have converted already one of the projects the 
> > XMLParser is dependent on: "OrderPreservingDictionary"
> > which lives at: 
> > https://github.com/pharo-contributions/OrderPreservingDictionary
> > It has the full history - but no reference to your username (because I 
> > guess Peter did not know your github name/mail address).
> 
> Ah cool I was about to do it. 

>From the history I guess Peter did it. 

But we should redo it once we know Monty's github user account name to have him 
linked in the 
history of commits and honour his authorship.

@Monty: can you tell us your github account user name/ github home?

Thx
T.

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

[Torsten Bergmann]

Hi monty,

yes - it is easy with https://github.com/peteruhnak/git-migration

It would be good to make it available on the more general location: 
https://github.com/pharo-contributions  
If you tell us your github name we can add you as member.

Note that Peter seem to have converted already one of the projects the 
XMLParser is dependent on: "OrderPreservingDictionary"
which lives at: https://github.com/pharo-contributions/OrderPreservingDictionary
It has the full history - but no reference to your username (because I guess 
Peter did not know your github name/mail address).

I guess we should also convert "Pastell" which is also helpful for XML 
processing and has XMLParser as dependency.

I can also help converting - just contact me or Norbert on Discord.

Thanks
Torsten (a.k.a "astares" on Discord)


> Gesendet: Donnerstag, 07. März 2019 um 11:19 Uhr
> Von: "monty" 
> An: pharo-dev@lists.pharo.org
> Betreff: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/
>
> I will move it to github, if that makes things easier for everyone else.
> 
> ___
> montyos.wordpress.com
> 
> 
> > Sent: Wednesday, January 30, 2019 at 3:13 PM
> > From: "Sven Van Caekenberghe" 
> > To: "Pharo Development List" 
> > Cc: monty 
> > Subject: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/
> >
> >
> >
> > > On 3 Oct 2018, at 07:43, monty  wrote:
> > >
> > > I am the principal maintainer of those projects, but any PharoExtras dev 
> > > can contribute. And the blog below (which I plan on updating) provides 
> > > additional information on them.
> >
> > Has there been any progress in this area ?
> >
> > It would be really great if this important project moved to GitHub.
> >
> > Sven
> >
> >
> 
>

Re: [Pharo-dev] How does Metacello decide what is already loaded ?

[Torsten Bergmann]

Hi Sven,

https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md

includes a chapter on load conflicts.

Thx
T.

Re: [Pharo-dev] DeleteVisitor and symbolic links

[Torsten Bergmann]

Sven wrote:
> Thanks, Alistair, for taking care of all this stuff.

+1

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

[Torsten Bergmann]

 
[ Pharo current ] fork

Re: [Pharo-dev] [ANN] Pharo 7.0 released!

[Torsten Bergmann]

Hi,

it's a nice release yes - and the best we ever provided indeed. I'm really 
happy too that P7 image is an 
official release now. 


But still:
==

In a post [1] in November 2017 I brought up the topic again to "increase the 
quality level in Pharo 7 and onwards". 

With 762 commits [2] for Pharo 7 I devoted a lot of time in fixing often simple 
and trivial things just to clean up 
comments, code, typos, packages, manifests, tests and so on. 

Many others did the same and supported these cleaning efforts. This helped 
adding a few more release tests to keep the 
quality bar on the level reached. Special thanks to Marcus, Esteban, and many 
others who helped reviewing, fighting a 
shaky CI server, integrating quickly and so on ...

Still THIS IS NOT FINISHED ... and it would be really help if more people would 
participate in the cleaning or fixing bugs.
Also many external packages now need some love to work with Pharo 7. 

We have a large community with many, many users - but still only a few 
contribute to the core system.

I wonder why and would like to know: 
  - Is it due to the switch to git ?
  - Is is due to the new contribution process?
  - Is it for other reasons?

Remember: Pharo is yours and even small steps could make a difference. So 
please join!

Thanks
T. 


[1]  
http://forum.world.st/Pharo-Quality-raising-the-quality-level-in-Pharo-7-and-onwards-tt5027111.html#none
[2]  https://github.com/pharo-project/pharo/graphs/contributors

Re: [Pharo-dev] [ANN] Preparing for release. No more PRs will be accepted on P7.

[Torsten Bergmann via Pharo-dev]

--- Begin Message ---
Hi Esteban,

Good news that we get closer to a release. :)

What is still the most annoying problem is that inbetween the build number had 
a hard reset during the switch to an "RC1" candidate
or after - so build numbers are currently at around "129" as you can see on the 
mails to the list.

The last shown by Pharo Launcher is 1436 builds with a Pharo 701436.

This is not only confusing - but still breaks the launcher download. Or did I 
miss something?

Thanks
Torsten

> Gesendet: Donnerstag, 17. Januar 2019 um 16:18 Uhr
> Von: "Esteban Lorenzano" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] [ANN] Preparing for release. No more PRs will be 
> accepted on P7.
>
> Unless is a show stopper, of course!
> 
> Please redirect your PRs to the branch Pharo8.0.
> 
> Esteban
> 
> 

--- End Message ---

[Pharo-dev] Managing of P7/P8

[Torsten Bergmann]

Hi,

as Pharo 8 development started I wonder:

  1. When will it be possible to already get a Pharo 8 latest image
 from ZeroConf. Because one requires ideally the latest image to contribute 
 - no?

 Or should one search/download from the CI server for the time being (which
 would be cumbersome)

  2. How will contributions still going to P7 handled regarding P8.
 Typically a bugfix for P7 should also go into the P8 image - no? 
 But from the integration mails floating around I do not see
 this is happening.

 I would expect that a PR for Pharo 7 would also be merged into Pharo 8 
branch.
 If not the images could easily diverge too much or done fixes for P7 will 
not be in P8.

Thanks in advance for clarification!

Bye
T.
 

Re: [Pharo-dev] ZeroConf trouble (curl/64bit)

[Torsten Bergmann]

Subbu wrote:
>>Does curl -L help?


Yes - the documented

curl https://get.pharo.org/64 | bash 

as mentioned on https://get.pharo.org/64/ FAILS
while 

curl -L https://get.pharo.org/64 | bash 

as well as 

curl get.pharo.org/64 | bash 

work.

Anyone able to change the template/docu on https://get.pharo.org/64 ?

Thx
T. 

[Pharo-dev] ZeroConf trouble (curl/64bit)

[Torsten Bergmann]

Using ZeroConf on a fresh Ubuntu machine:

  wget -O- https://get.pharo.org/64 | bash

works but

curl https://get.pharo.org/64 | bash

as mentioned on https://get.pharo.org/64/ gives an error:


  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   237  100   2370 0556  0 --:--:-- --:--:-- --:--:--   555
bash: line 1: syntax error near unexpected token `newline'
bash: line 1: `'


The 32 bit curl works

Re: [Pharo-dev] Happy new year!

[Torsten Bergmann]

Happy new year - I'm sure 2019 will be another good year for Pharo

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

[Torsten Bergmann]

and

  11. There is no https://get.pharo.org/80 yet ...

Bye
T.

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

[Torsten Bergmann]

Hi Esteban,

you know I'm neither shy on contributing nor doing any work for Pharo but 
personally I think we open Pharo 8 too early and should better focus our 
efforts more 
on finalizing P7 (see below) instead of opening the next construction site.

Things were already shaky and sometimes painful with P7 - nonetheless I managed 
to get 762 commits into it. Often simple or boring PR's just to get packages, 
classes, methods 
in shape and clean up. Funny enough I can now say I'm on top of 
https://github.com/pharo-project/pharo/graphs/contributors ;)

I had a hard time finding out how things work in the new git/pharo/externally 
managed projects combination - sometimes also with broken or unfinished tools. 
A newly opened
P8 so early adds even more on top...

Several things directly came into my mind:

 1. http://bugs.pharo.org now points to nirvana now

 2. http://ci.pharo.org  point to nirvana now as well

 3. It's unclear to me what will happen to the bugtracker mailinglist archive. 
Currently I often use it to stay informed about our changes.
Will it stop in december?

https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/

 4. The CI for Pharo 7 was not green in most of the latest commits ... and 
situation for Pharo 8 is not even better now: RED all over on


https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/

 5. We still have dirty packages in Pharo 7 - the last remaining issue here 
https://github.com/pharo-ide/Calypso/issues/386
is still not solved and there was no reaction on Discord after reminding it 
twice.

 6. Calypso still has hard issue in Pharo 7 - most of them already fixed in 
Calypso project.

But integration of the new Calypso version is still pending  
https://github.com/pharo-project/pharo/pull/2115 

Nonetheless we already switch to P8?

 7. A change done lately (around 17.12.) was resetting the build numbers - so 
for whatever strange reason we started with 1 again
althoug we were already at Build 1416 for Pharo 7 with all the integrations.
 

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/

This build number issue was not yet fixed although this is a serious issue 
to compare image buils or be able to download using Launcher.

Nonetheless we already switch to P8?
 
 8. Lately we switched the branches from "development" to "Pharo7.0" and now 
also "Pharo8.0". This was also just announced - without any discussion
in advance forcing people to resetup their tools and local repos.

This change is still not event reflected in the contribution guideline ... 
but we already switch to Pharo 8

 9. We still have lots of important and must-fix cases for Pharo 7 
https://pharo.fogbugz.com/f/filters/1412/7-0-All

10. There was nothing said about backporting strategy between the new P8 and P7 
now...


To me it would already help a little bit to clarify the above raised points and 
get a more detailed info about the next P7 steps towards the release.

Independent from that I fear we constantly decouple more and more people with 
too many process and contribution scheme changes at once. From the discussions 
on Discord I already see many people struggle - and often not only the 
beginners.

Bye
T.

Re: [Pharo-dev] Catalog Entries

[Torsten Bergmann]

Ben wrote
>"If the tag is edited on the server, but the local one is old" 

Yes - there could be an issue with this "tag moving" approach if the server is 
not checked
for new tags / moved tags and the version from the local repo cache is loaded - 
because
you might load an outdated while the server already has a newer 
"latest-release".

When I think a second time I guess what Sven wants could maybe also be achieved 
with another
model:

 - having the "master" branch for development and tagged releases 1.0, 2.0, 3.0 
and so on
 - having a second "latest-release" branch where the current latest tag from 
master is just pulled/merged in
   Anytime you make a new release version in master you just pull it into this 
"latest-release" branch

This has several benefits:

 - you can use the same stable load expression with stable URL: 
github://svenvc/ztimestamp:latest-release 
 - you just tag in master as usual
 - when a new release was tagged in master you just switch to the 
"latest-release" branch, pull from master
   and push to github (easier than tag moving)
 - the graph ("Insights" -> "Network") shows you if you already pulled the 
latest tagged version from master
   into the "latest-release" branch and also shows you how far ahead you are 
with master in case of further 
   development

Also when the latest release has some trouble but your master development is 
not yet ready for a full new version
you can hot-fix it in the "latest-release" branch to help people. Later when 
you are ready with another full new
version you will have the branches resynched then anyway.

I'm not sure if this model also has some drawbacks - but as it looks now this 
seems a better option... 

Bye
T.

Re: [Pharo-dev] Catalog Entries

[Torsten Bergmann]

JOKING:"lastRelease" is fine, there is no release afterwards anymore as it 
is completed by 100% ;) 

SERIOUS:   "latest-release" seems appropriate

Re: [Pharo-dev] Catalog Entries

[Torsten Bergmann]

Hi Sven,

so if I understood you correctly you want a single branch for development - 
lets assume you directly use
master for that.

If you just load the branch you get the "latest development" things that are 
still 
work in progress.

Then from time to time you tag a version for release: 1.0, 2.0, 3.0 in your 
master branch.

If today 3.0 is your latest release they should have a load expression to load 
3.0. 
If tomorrow you tag a new release 4.0 you want to them to use the same load 
expression to
get the "latest released".

Right?

There is no specific meta-tag for that. But as a tag is nothing more than a 
string applied to a commit for later reference
you could additionally tag the commit of 3.0 with a tag "latest" or 
"latestRelease" and then later (after 4.0 is released)
move this tag to the commit that was used for building a new 4.0.

I have not tried but as you could delete and/or move tags in git this should be 
doable in git without any 
problem. Just google for "tag moving" and "git".

Metacello itself does not care - it then will use

 Metacello new
   baseline: 'ZTimestamp';
   repository: 'github://svenvc/ztimestamp:latestRelease';
   load.

to ask git for the tag. But it is your responsibility to move the tag 
"latestRelease" forward manually anytime
you do a new release.

As you usually tag locally - remember to push the tags afterwards. Double 
checking afterwards in GitHub helps
here. The command

  git push -f --tags

could be helpful here. 

Hope this solves what you require.

Thanks
Torsten







> Gesendet: Dienstag, 18. Dezember 2018 um 12:54 Uhr
> Von: "Sven Van Caekenberghe" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] Catalog Entries
>
> 
> 
> > On 18 Dec 2018, at 12:48, Torsten Bergmann  wrote:
> > 
> > Hi Sven,
> > 
> > did you try to just use the branch name as in the other model.
> > 
> > Metacello new
> >   baseline: 'ZTimestamp';
> >   repository: 'github://svenvc/ztimestamp:master';
> >   load.
> > 
> > then it should load the latest from this branch independent from the
> > tags.
> > 
> > Bye
> > T. 
> 
> I know about master and what it means, but that is not exactly what I want.
> 
> When you release, that is a deliberate action: you put a stamp on the current 
> project timeline, declaring it as ready/stable enough for people to depend on.
> 
> The master branch can further evolve after a (latest) release. It is the next 
> release candidate.
> 
> I would like to depend on whatever released version is the latest. See the 
> URLs in my previous email.
> 
> 
> 

Re: [Pharo-dev] Catalog Entries

[Torsten Bergmann]

Hi Sven,

did you try to just use the branch name as in the other model.

 Metacello new
   baseline: 'ZTimestamp';
   repository: 'github://svenvc/ztimestamp:master';
   load.

then it should load the latest from this branch independent from the
tags.

Bye
T. 

Re: [Pharo-dev] Catalog Entries

[Torsten Bergmann]

Hi Sven,

Maybe we have better ideas when we move forward with the transition to git for 
the majority of external 
projects. But for the time being I guess we stick to Catalog as a replacement 
is still not available. 
It might not be the best solution - but at least it works. The only downside is 
that it is still dependent 
on SmalltalkHub due to the MetaRepos hosted there.

To answer your questions:

For Pharo 7.0 there is a regular MetaRepo

   http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo70

that one can use. The (re)indexing each day is still based on providing a 
ConfigurationOf... there.
We will create a MetaRepoForPharo80 once Pharo 7 is released and Pharo 8 work 
starts.

Catalog also does not work directly with BaselineOf - so you point from your 
ConfigurationOf to a BaselineOf in Github
as the examples below will demonstrate.

So while the basic mechanism of Catalog did not change and works as before the 
usage of git and GitHub gives you now more 
flexibility in the management of your (catalog) projects. 

I already use this for a few of my projects that I moved to GitHub and I would 
share some experience here.
Basically I tried now two different models:

Model 1: Work with a single branch and close a release using a tag as version 
in git
===
This is I guess how Iceberg, Calypso and others are maintained now. You work on 
a specific (development) branch and
use the git tagging to mark release like milestone of your project ("versions").

This is the model I started to maintain ConfigurationOfTealight (which you will 
find in catalog
and in https://github.com/astares/Tealight)

So I tagged in git when I reached something shareable as you can see on the 
first releases: https://github.com/astares/Tealight/releases
and then reference this git tagged version in my ConfigurationOfTealight:

v0_0_4: spec


spec for: #'common' do: [ 
spec blessing: #'stable'.
spec
baseline: 'Tealight' with: [ 
spec 
className: 'BaselineOfTealight';
repository: 
'github://astares/Tealight:0.0.4/repository' ]]


The advantage is that you use git to tag the releases, it is a reproducable 
stable version then and GitHub shows it on 
the "releases" tab. One typically can not modify the release afterwards (which 
is not 100% true as git tags could be moved but this is
another story).

So with this model you form and finalize/close a release by tagging in 
git/GitHub and reference it in your ConfigurationOf

Model 2: Work with several open branches - one per Pharo version


In DesktopManager which is on https://github.com/astares/Pharo-DesktopManager I 
do it differently. I wanted to maintain it for Pharo7
now but wanted to still easily backport changes to Pharo 6.

For this project I maintain therefore two special branches "pharo6" and 
"pharo7" - each for a particular Pharo version. 

So in the ConfigurationOfDesktop as you will find in MetaRepoForPharo70 I just 
point to the Baseline 
with only the difference of the branch:


pharo6: spec


spec for: #'common' do: [ 
spec
baseline: 'DesktopManager' with: [ 
spec 
className: 'BaselineOfDesktopManager';
repository: 
'github://astares/Pharo-DesktopManager:pharo6/src' ]]

pharo7: spec


spec for: #'common' do: [ 
spec
baseline: 'DesktopManager' with: [ 
spec 
className: 'BaselineOfDesktopManager';
repository: 
'github://astares/Pharo-DesktopManager:pharo7/src' ]]

stable: spec


spec for: #'pharo5.x' version: '0.2.0'.   "old way using versioning 
with Monticello/Metacello and StHub"
spec for: #'pharo6.x' version: '6.0'. "still open version branch 
from Pharo 6 using git and GitHub"
spec for: #'pharo7.x' version: '7.0'. "still open version branch 
from Pharo 7 using git and GitHub"



This allows me to maintain the differences between the Pharo 6 and Pharo 7 
version by using the two distinguished branches
and backport from the "pharo7" 

Re: [Pharo-dev] Fwd: Tonel sourceDir

[Torsten Bergmann]

Hi Ben,

in Pharo 7 Iceberg works different - the source dir is part of the metadata in 
the repo
(right click on a repo and say "Repair" so it offers you to add metadata).


So for instance 

   https://github.com/astares/Pharo-OS-Windows

is already converted to the "latest and greates" and has a .project file with

{
'srcDirectory' : 'src'
}

So you just can load it without giving the source dir explicitly.

Also note that the src file directory has .properties file depicting the format:

{
#format : #tonel
}

Tonel is now recommended. Hope that helps a little bit.

Thanks
T.

[Pharo-dev] ZnCharacterReadWriteStream is missing #tab

[Torsten Bergmann]

Hi Sven,

in latest P7 I get an error when loading my Bootstrap 4 project:

https://github.com/astares/Seaside-Bootstrap4

about

MessageNotUnderstood: ZnCharacterReadWriteStream>>tab

This is sent from STONWriter>>newlineIndent.

To reproduce please use the following load expression:

   Metacello new
  baseline:'Bootstrap4';
  repository: 'github://astares/Seaside-Bootstrap4:master/src';
  load


If the missing method in ZnCharacterReadWriteStream is implemented like

 tab
writeStream tab

it works.

As I'm constantly unclear about how Zinc (and some other externally maintained 
packages) 
are managed now I would kindly ask you to integrate it. Thanks in advance!

Bye
T.

[Pharo-dev] :: Separator in class names

[Torsten Bergmann]

Again several years passed by and we still have no solution for Namespaces.

At least I would like to have support for a separator. Details are in this 
thread from 2016 (!):

  http://forum.world.st/Separator-in-class-names-td4926162.html

I still ask if this is something we can get on board for P7 or P8?

Thx
T.

[Pharo-dev] Mailing list Archive - Bandwidth Limit Exceeded

[Torsten Bergmann]

Hi Marcus,

I receive a "Bandwidth Limit Exceeded - The server is temporarily unable to 
service your request due to the site owner reaching 
his/her bandwidth limit. Please try again later." message on 
http://lists.pharo.org

If I remember correctly we already had this one or two years ago.

Thanks
T.  

[Pharo-dev] Deprecation guide for methods, classes and packages

[Torsten Bergmann]

Hi,

>From Bug #20900/ PR 1818 it looked like it is not really clear on how to 
>"deprecate" correctly. Therefore I summarized and
wrote a short guide following what we contributors used as best practice so 
far. Also read [1], [2] and [3] and check some of the 
deprecation settings in the Pharo settings browser. Just open SettingsBrowser 
and search for "Depre".

I write this mail to "pharo-dev" with CC: "pharo-users" list - because of 
common interest. But comments and replies should
please go to "pharo-dev" so we do not disrupt the thread too much. Thanks!

Please review what I wrote and ideally we can put the text or a link to it as 
"Deprecation guide" into the documentation
 / wiki / ... on GitHub afterwards.

Hope this helps a little bit.

Thanks
T.

[1] https://en.wikipedia.org/wiki/Deprecation
[2] 
https://www.peteruhnak.com/blog/2015/08/06/transforming-deprecated-code-with-rewritetool/
[3] 
https://pharoweekly.wordpress.com/2016/06/17/automatic-deprecation-refactoring/

--
In any Pharo version we have a special package hosting deprecated methods and 
classes. This allows smooth migration for Pharo users
as code should still load and runs to some extent - but deprecation warnings 
and possibly a helping hand (in form of automatic
code transformations) could be given to support migration.

As we currently work on Pharo7 there is a "Deprecated70" package in the image 
hosting deprecated methods and classes intended to be
removed for Pharo 8. When Pharo 7 is released the users can easily spot the 
deprecations - also because they are striked through
(more on this below). When Pharo 8 iteration starts the "Deprecated70" will be 
replaced with an empty "Deprecated80" package.


DEPRECATING METHODS
===   

   If you deprecate a METHOD use #deprecated: message and switch it to be an 
extension method in *Deprecated70*. If the 
   method could be replaced by calling another method then dispatch the call to 
the new method and ideally provide a transformation
   so next time the old method is called the sender method is automagically 
rewritten and could be adopted/migrated:

oldMethod 
"An old method we do not use anymore. But luckily there is a 
replacement."  

self deprecated: 'Please use #newMethod instead'
  transformWith: '`@receiver oldMethod' -> '`@receiver newMethod'.

^ self newMethod

So if there is a method like 

   foo
 self oldMethod 

sending the old deprecated method it will be migrated to

   foo
 self newMethod 

as soon as foo, the oldMethod and the transformation is called. If the 
automatically migrated method is under version
control (Monticello or git) you will easily see that #foo was modified.

In case there is no replacement for a method you would like to deprecate 
then it is best to throw an error when it is used:

veryOldMethod 
   "A very old method hopefully nobody uses. So we do no provide a 
replacement."

self deprecated: 'The method #veryOldMethod is deprecated without 
any replacement'.

   ^ self error: 'Do not use #veryOldMethod anymore'

Note that the method is striked through in the Pharo system browser in both 
cases to show that it should not be used anymore.

In the standard image calling a deprecated method is logged on the 
Transcript and flagged with a warning dialog. This should
help users and maintainers of external packages to easily spot when they 
still use deprecated code.
You can change these settings in Pharo Settings Browser under Tools -> 
Debugging -> Deprecation Handling.

DEPRECATING CLASSES
===

   If you deprecate a CLASS implement #isDeprecated on class side to return 
true and move it to package "Deprecated70"
   Ideally write in the class comment why it is deprecated and if there is a 
replacement class what to use instead

Object subclass: #OldClass
instanceVariableNames: ''
classVariableNames: ''
package: 'Deprecated70-OldTag'

and comment to explain the reasons:

 OldClass comment: 'Use NewClass instead'.  

and implement in class side method category 'testing'  
 
   isDeprecated
  "We do not need this class anymore"
  ^true

Note that the class is striked through in the system browser.


DEPRECATING PACKAGES


   If you deprecate a PACKAGE then rename it with "Deprecated" in the name. Let 
the class side of the package manifest 
   (typically a subclass of PackageManifest within the package) als return 
#isDeprecated with true. In the class
   comment of the package manifest (which also serves as package comment) 
explain why the package is deprecated and
   if there is a replacement or not.
 

[Pharo-dev] UndefinedClasses as first class entities for P7

[Torsten Bergmann]

At ESUG 207 there was a presentation about UndefinedClasses as first class 
entities.

According to the slides:

https://de.slideshare.net/esug/firstclass-undefined-classes-for-pharo-from-alternative-designs-to-a-unified-practical-solution

this was planned for inclusion into Pharo 7. 

Is this still on the plate? Any status?

Thanks
T.

Re: [Pharo-dev] Release test for unused temps and other

[Torsten Bergmann]

Thank you all for your feedback - so let's do it with a TestCase added into 
the image.

PR is available, according CI is green and ready for review/integration:

   https://github.com/pharo-project/pharo/pull/1782
 

[Pharo-dev] Status fo Stream changes in Pharo 7

[Torsten Bergmann]

Hi,

In Pharo 7 there were changes applied to rework the streams. I understand that 
we might have
reasons to change it - but to me this looks incomplete and not finished.

For instance "FileStream" is a deprecated class - but still a lot of code in the
image is referencing it instead,

Is there a guide or plan for all these methods being reworked to use a 
(hopefully 
compatible) alternative. 

Can anyone involved in this topic give an update on the status? 

Thanks
T.

[Pharo-dev] Streams and FileDialog in Pharo 6 and 7

[Torsten Bergmann]

Hi,

A question to those who worked on the new streams for Pharo 7:

 
In PHARO 6 I used the following expression to open a file dialog and let the 
user choose 
a binary file: 

s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').

This returned 
 - either nil (when file dialog was canceled) 
 - a "MultiByteFileStream" instance when a file was selected

The MultiByteFileStream instance already had the name of the file (= full path) 
and I was 
able to query it for further use:

 s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
 s name inspect

(for instance to display which file is processed in a window by showing the 
full path)



Now in PHARO 7 same expression returns an instance of ZnCharacterReadStream (as 
MultiByteFileStream
is deprecated):

 s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').

and  ZnCharacterReadStream  does not understand #name - and in fact the info 
about the name is 
totally lost/not available. To me this looks missing/broken.

So what is the recommended way in Pharo 7 to open a file dialog, let the use 
choose a file
 and get a file stream but also the name? IMHO this is either broken or 
missing...

Thanks
T.

[Pharo-dev] Release test for unused temps and other

[Torsten Bergmann]

Hi,

the very nice contribution on GIFReadWriter/animated images (see 
https://pharo.manuscript.com/f/cases/22137)
unfortunately introduced some methods that had no sender, were uncategorized 
and had unused temporary variables, etc.

Something that is meanwhile shown by our tools and easy to fix. I guess it was 
some overseen leftover. Unfortunately this 
also slipped through the integration process as it was merged without an 
approval from a community reviewer. 

I dont want to lament too much on this specifc case (especially as I now fixed 
it in  https://pharo.fogbugz.com/f/cases/22426).

But after I cleaned the P7 image this spring to not have unused temporaries 
anymore I was suprised to find such 
glitches again now. So to me it shows that we need to write more tests to 
detect violations and keep our achieved quality standards 
up and also should not solely rely on the review process.  

Otherwise we need to invest our time in cleaning up our own stuff afterwards 
again and again. 

To be specific one can evaluate:

CompiledMethod allInstances select: [:m | m ast temporaries anySatisfy: [:x 
| x binding isUnused ]].

to find unused temps - which would be easy to package up into one of the 
release test to ensure no unused temp vars are left
(the tearDown would require an "ASTCache reset").

The problem is that this simple test would take around 20-30 seconds depending 
on machine and I do not know if it would be a 
good idea/good solution to integrate. Especially I'm not sure if it is worth 
the issue or will kill the CI again and again.

What do you think about it? Comments appreciated?

Thanks
T.

 

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

[Torsten Bergmann]

Hi Pablo,

 

were you able to have a look at my changeset with the fix provided in July already:

 

http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272614.html


 

I would like to get https://pharo.fogbugz.com/f/cases/22271/Fix-IndexedSlots-in-combination-with-StatefulTraits

fixed.

 

Thanks

T.

 


Gesendet: Dienstag, 17. Juli 2018 um 12:51 Uhr
Von: "Torsten Bergmann" 
An: pharo-dev@lists.pharo.org
Cc: Pharo-dev 
Betreff: Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits



Hi Pablo,

 

thanks for the quick answer. The attached CS would fix it ... can you have a review so we can open a bug and do a PR?


Then at least this could be integrated independent from when the tools and traits are cleaned up.


Thanks
T.

[Pharo-dev] Pharo and Docker (some steps)

[Torsten Bergmann]

For those interested in Docker: 

I recently played with Pharo and Docker and summarized some of my steps in a 
small tutorial
in my Pharo wiki:

http://wiki.astares.com/pharo/613

There is also a page following Mike Filonovs suggestions on the Pharo docker 
file:

   http://wiki.astares.com/pharo/615  

Maybe this is useful for others too.

Bye
T.

Re: [Pharo-dev] Reducing the cost of documentation

[Torsten Bergmann]

Hi Alistair,

I don't think the contribution process hold people back from writing 
documentation since providing a contribution is easy to do now (see [1] and 
[2]).

And (even when more cumbersome) I like the review process - as it helped
several times in the past to discuss contributions or even fixing them or find 
trivial typos.

I guess the primary problem is lazyness: people dont like to write 
documentation as it is always additional effort. Remember that often people 
do not even write a simple comment on a class to inform about the purpose 
it was created...

I personally doubt that we increase the number and quality of the provided 
in-image docu with the proposal. 

Bye 
T.

[1] https://github.com/pharo-project/pharo/blob/development/CONTRIBUTING.md
[2] https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo



> Gesendet: Montag, 20. August 2018 um 08:37 Uhr
> Von: "Alistair Grant" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] Reducing the cost of documentation
>
> Hi Everyone,
> 
> The topic of documentation recently came up again on the squeak list and
> it made me wonder about some of the blocks that currently prevent more
> contributions to in-image documentation.
> 
> One of the things holding back the in-image documentation is that the
> cost of contributing is too high: apart from actually making the change
> we currently have to (maybe) open an issue, create a branch, commit and
> open a PR.  Someone with commit privileges then has to review the PR
> enough and decide to merge it.  We then need to manually delete the
> branch some time later.
> 
> This is one of the reasons that wikis have been successful, they lower
> the cost of making changes.
> 
> We could extend iceberg to automatically submit PRs for documentation
> only commits (it could be a separate option, so that the doco only
> requirement is enforced), and set up github to auto-accept the PR.
> Modifying in-image documentation would then become a few extra clicks,
> significantly lowering the cost.
> 
> I'm not familiar with Jenkins, or any other CI system, but hunting
> around google it looks like it may be possible to directly implement
> this, if not there are services such as https://mergify.io/ which
> advertise being able to do this by using flags in the CI to determine
> whether the PR should be merged (disclaimer, I've never looked at
> mergify.io, just found it while thinking about this).
> 
> Thoughts?
> 
> 
> Cheers,
> Alistair
> 
> 

[Pharo-dev] Uncomitted changes in latest image

[Torsten Bergmann]

There are uncomitted changes in the latest Pharo image 
(Pharo-7.0+alpha.build.1176.sha.eedde11d2331266218204b1bb5c77a9037b7a706 (64 
Bit))
for some packages.

Got the image out of sync with the sources?

[Pharo-dev] ZnHeaders should allow custom or empty Server info

[Torsten Bergmann]

Hi Sven,

when running a Zinc Server

ZnServer startDefaultOn: 8080. 

the server currently reveals the framework, the framework version and the Pharo 
version
the server is running on as part of the HTTP communication. 

For instance 

  (ZnEasy get: 'http://localhost:8080') headers  at: 'Server'

would give 

  Zinc HTTP Components 1.0 (Pharo/7.0)

in the Server Header.

While this is nice for debugging and during development this can be a problem 
in more
secured/pentested environments where usually specific headers are turned off to 
not 
give specific informations to an attacker (to allow him to find vulnerabilities 
of specific
versions or servers).

While headers could be changed rewritten in front-ends or load balancing 
servers we
can not assume that Pharo images work as backend server always. Webservers like 
Nginx, 
Apache, IIS, Express in JS, PHP and other allow to disable/modify these 
headers. 

Using the attached changeset it is possible to modify the Server header and 
customize it:

 ZnHeaders serverString: 'MoreSecureServer'

If the server string is not customized the default server string is used as 
before.

We should make sure this is integrated into Pharo 7 but also into the Zinc 
framework.
I opened a bug 
https://pharo.fogbugz.com/f/cases/22317/ZnHeaders-should-allow-custom-or-empty-Server-info

As Zinc is also managed externally how should we proceed?

Thx
T.



ZincCustomServerName.1.cs
Description: Binary data

[Pharo-dev] ZnHTTPSTests and more CI trouble

[Torsten Bergmann]

Latest build fails with #testGetPharoVersion when run manually because this 
Test is calling

https://ci.inria.fr/pharo/job/Pharo-6.0/lastSuccessfulBuild/api/xml?xpath=/*/fullDisplayName

currently returning an error.

Re: [Pharo-dev] Is Jenkins OK?

[Torsten Bergmann]

For future reference: https://github.com/pharo-project/pharo/pull/1687
 

Gesendet: Dienstag, 14. August 2018 um 10:45 Uhr
Von: "teso...@gmail.com" 
An: Pharo-dev 
Betreff: Re: [Pharo-dev] Is Jenkins OK?


I am disabling the testing on OS X until the slave come back from the grave!!
 

So we can continue working!

 

Cheers.

 


On Tue, Aug 14, 2018 at 10:03 AM Alistair Grant  wrote:

On Tue, 14 Aug 2018 at 09:59, Guillermo Polito
 wrote:
>
> Nope, the osx slave is down since yesterday.
> https://ci.inria.fr/pharo-ci-jenkins2/computer/pharo-ci-jenkins2-osx/
>
> I've been trying to restart it but no luck so far...
> I'll keep you updated.


Thanks, Guille!

Cheers,
Alistair


>
>
> On Tue, Aug 14, 2018 at 7:49 AM Alistair Grant  wrote:
>>
>> I have a PR that has been running for over 13 hours...
>>
>> https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pending%20pull%20request%20and%20branch%20Pipeline/detail/PR-1684/1/pipeline
>>
>> (if there's something I can do about this myself instead of annoying
>> the list, please let me know)
>>
>> Thanks,
>> Alistair
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - http://www.cnrs.fr
>
>
> Web: http://guillep.github.io
>
> Phone: +33 06 52 70 66 13
 

 

 
--

Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

[Torsten Bergmann]

Hi Pablo,

 

thanks for the quick answer. The attached CS would fix it ... can you have a review so we can open a bug and do a PR?


Then at least this could be integrated independent from when the tools and traits are cleaned up.


Thanks
T.

FixIndexSlottedTraits.cs
Description: Binary data

[Pharo-dev] IndexedSlots in combination with StatefulTraits

[Torsten Bergmann]

I guess I found a bug in accessing Slots using #slots in combination with 
IndexedSlots and traits.
To reproduce use latest Pharo 7 (Build 1126)

First create a class with a slot, note that the slot needs to be :

Object subclass: #ClassA
slots: { IndexedSlot named: #upper }
classVariables: { }
package: 'Slot-Bugs'

As it is the first slot it internally receives an index 1 as you can check with 
"ClassA slots first".

Now define a stateful trait with another indexed slot:

Trait named: #StatefulTrait
uses: {}
slots: { IndexedSlot named: #slotFromTrait }
category: 'Slot-Bugs'   
 
And create a new subclass using the new Trait

ClassA subclass: #ClassB
uses: StatefulTrait
instanceVariableNames: ''
classVariableNames: ''
package: 'Slot-Bugs' 
 

1. when you evaluate "ClassA slots"  it returns {#FirstSlot => Slot} which is 
correct
2. when you evaluate "StatefulTrait slots"  it returns {#slotFromTrait => Slot} 
which is correct
3. when you evaluate "ClassB allSlots"  returns  "an OrderedCollection(#upper 
=> InstanceVariableSlot #slotFromTrait => InstanceVariableSlot)" which is OK

but  

4. when you evaluate "ClassB slots" it returns  {#slotFromTrait => 
InstanceVariableSlot} which is NOT correct as class B does not define the slot, 
it is defined in the trait

 
So I think 4. is wrong and reasons is the implementation of #slot:

  slots
"I remove the slots comming from a traitComposition"
^ super slots reject:[ :e  | self traitComposition slots includes:e ]   
 

If you debug you will notice that 

   super slots   returns our #slotFromTrait with an index of 2 
while 
   self traitComposition slots   returns our #slotFromTrait with an index of 1 
while 

which is the same #slotFromTrait but a different index - therefore it does not 
get removed.

 
Dont know what is the best way to fix this without any side effects. Commenst 
and help appreciated. 

Thanks
T.

Re: [Pharo-dev] [Ann] Iceberg v1.1.1

[Torsten Bergmann]

Great - thank you! Might be a small patch release - but nonetheless important.


BTW: the links in your mail are pointing to PR's of Pharo and not Iceberg. If you used
         a template you might want to consider changing it.
 

 

Gesendet: Montag, 18. Juni 2018 um 17:47 Uhr
Von: "Guillermo Polito" 
An: "Any question about pharo is welcome" , "Discusses Development of Pharo" 
Betreff: [Pharo-dev] [Ann] Iceberg v1.1.1


Hi everybody,
 

This week we have a small patch release of Iceberg, version v1.1.1.

This version will be available in the next Pharo build.

 

In summary, this release fixes two issues with the new credentials manager, and introduces a couple of other enhancements/bugfixes.

 

Below you will find the detailed changes log.

Enjoy,

Guille

 


Integrate Iceberg 1.1.1
https://pharo.fogbugz.com/f/cases/22168/Integrate-Iceberg-1-1-1

https://github.com/pharo-vcs/iceberg/releases/tag/v1.1.1

#864 Repairing Missing repositories lead to wrong source directory
#861 update tonel to v1.0.9
#836 DefaultBackendType class variable is unused
#862 Iceberg tests are not running in Pharo 7
#852 Make error dialogs copy-pastable
#858 IceTipReadOnlyTextMorph does not allow select and copy anymore
#850 Change Detached head status from error to warning if we are on a tag
#853 Clone dialog "username" is confusing
#860 CredentialStore API
#854 Error in History window


 
 
--






	
		
			
			   
			
			
			Guille Polito

			Research Engineer

			 

			Centre de Recherche en Informatique, Signal et Automatique de Lille

			CRIStAL - UMR 9189

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

			 

			Web: http://guillep.github.io

			Phone: +33 06 52 70 66 13
			
		
	

[Pharo-dev] Window groups and Calypso Browser

[Torsten Bergmann]

Hi Denis,

when I open a Pharo window (like Playground) and select "Create window group" I 
can 
drag and drop other windows onto it. So one can group several windows into one, 
each
one shown with an own tab.

This works for most of the Pharo windows (Playground, Iceberg, ...) in latest 
Pharo 7 - but 
not for the Calypso browser.

I can drag a system browser into the window group - but when I drag it out 
again it is just a gray
window and the content is not usable anymore.

I guess this is a bug in Calypso - so I opened 
https://github.com/pharo-ide/Calypso/issues/287

Thx
T.

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

[Torsten Bergmann]

>Guille & Cyril wrote>
> > Since some decades now the default way to display a menu in applications
> > is to have a bar at the top of the windows. 


Alistair wrote
>> Instead of a menu bar at the top, which takes quite a bit of space,
>> and as mentioned may not fit on a small screen how about a "Start" 
>button in the task-bar that pops up the menu a-la Windows


So this basically reduces to the two UI options:

 1. Should Pharo look like an application (and have the menu at the top)

 2. Should Pharo look like an OS itself (with a primary "Start" menu in the 
taskbar as on Windows)

Maybe we should support both styles using a setting.

Bye
T.

Re: [Pharo-dev] [Pharo-users] Pharo 10th Anniversary

[Torsten Bergmann]

Yes - we should be happy to have left behind ugly "saphire". It would have 
never 
been our future - just look at it now. Not much progress till today - 
especially 
compared to Pharo. ;)

And happy anniversary Pharo :)

Each day another little step - I'm impatient to see where Pharo will be in 2028 
and especially in 2058 ...

Bye
T.

> Gesendet: Mittwoch, 30. Mai 2018 um 15:14 Uhr
> Von: "Norbert Hartl" 
> An: "Pharo Dev" 
> Cc: "Pharo users users" 
> Betreff: Re: [Pharo-users] [Pharo-dev] Pharo 10th Anniversary
>
> Happy saphire deprecation day!!!
> 
> Norbert
> 
> > Am 30.05.2018 um 10:10 schrieb Sven Van Caekenberghe :
> > 
> > Hi,
> > 
> > This short post by Stéphane Ducasse is worth sharing:
> > 
> >  https://pharoweekly.wordpress.com/2018/05/29/pharo-got-10-years/
> > 
> > Congratulation !
> > 
> > Sven
> > 
> > --
> > Sven Van Caekenberghe
> > Proudly supporting Pharo
> > http://pharo.org
> > http://association.pharo.org
> > http://consortium.pharo.org
> > 
> > 
> > 
> > 
> > 
> 
> 
>

[Pharo-dev] ZeroConf and Launcher

[Torsten Bergmann]

ZeroConf (get.pharo.org) is nice - as it allows to easily 
setup a new machine with a fresh image.

What about having the ability to download the latest
Launcher using a zeroconf script too?

Re: [Pharo-dev] Seaside loading broken in Pharo 7

[Torsten Bergmann]

Hi Sven,

it would be good to have a new #stable for Zinc (at least for recent Pharo 7).

Pharo 7 now has  
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-May/271651.html
integrated - but loading Seaside loads the current (old) stable definition and 
with that
an outdated Zinc breaking things. 

So one is still not able to use Seaside with the recent image and since 
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-March/270564.html
another two months passed by.

Would it be possible?

Thx
T. 



> Gesendet: Donnerstag, 22. März 2018 um 23:07 Uhr
> Von: "Torsten Bergmann" <asta...@gmx.de>
> An: pharo-dev@lists.pharo.org, seaside-...@lists.squeakfoundation.org
> Betreff: Re: [Pharo-dev] Seaside loading broken in Pharo 7
>
> Seaside is working ... but it is not possible to develop as by patching Zinc
> the Iceberg tool in P7 is broken then and one can not commit anymore. 
> 
> So be warned when you follow and use the script below.
> 
> :(
> 
> 
> 
> 
> > Sven wrote:
> > >You must be looking somewhere else,
> > >http://mc.stfx.eu/ZincHTTPComponents/
> > >find 'Character-Encoding-Core', they are all there.
> > 
> > 
> > 
> > Hmmm ... mysterious ... I checked two times yesterday using a web browser 
> > after the 
> > loading trouble in Pharo and it was not there.
> > 
> > 
> > Works now using:
> > 
> > 
> > Gofer it
> >   url: 'http://mc.stfx.eu/ZincHTTPComponents';
> >package: 'Zinc-Character-Encoding-Core';
> >   load.
> > 
> > Metacello new
> >   baseline:'Seaside3';
> >repository: 'github://SeasideSt/Seaside:master/repository';
> >load.
> > 
> > 
> > Thanks
> > T.
> > 
> >

Re: [Pharo-dev] [ANN] Alternative Pharo-contributor tool now explained with videos

[Torsten Bergmann]

Hi Sven,

I know but all roads lead to rome. It might be helpful as another way (thats 
why "alternative") nonetheless.

Thx
T.

> Gesendet: Freitag, 18. Mai 2018 um 13:43 Uhr
> Von: "Sven Van Caekenberghe" <s...@stfx.eu>
> An: "Pharo Development List" <pharo-dev@lists.pharo.org>
> Cc: "Any question about pharo is welcome" <pharo-us...@lists.pharo.org>
> Betreff: Re: [Pharo-dev] [ANN] Alternative Pharo-contributor tool now 
> explained with videos
>
> 
> 
> > On 18 May 2018, at 12:41, Torsten Bergmann <asta...@gmx.de> wrote:
> > 
> > https://github.com/astares/pharo-contributor
> > 
> > now provides two videos demonstrating how this tool can be used as an 
> > alternative to easily contribute to latest Pharo 7
> > 
> > 
> > VIDEO 1
> > https://www.youtube.com/watch?v=z4PWGxihdxU
> > 
> > VIDEO 2
> > https://www.youtube.com/watch?v=24ERozCePME
> 
> Nice, very detailed, step by step explanation, well done and thank you for 
> sharing this.
> 
> With the latest Iceberg (with the 'Repair ...' technology), you get a similar 
> experience (I know you wrote your tool earlier). You can also do the PR in 
> Pharo itself now (but doing in the Github web UI is OK too).
> 
> Sven
> 
> 
> 

[Pharo-dev] [ANN] Alternative Pharo-contributor tool now explained with videos

[Torsten Bergmann]

https://github.com/astares/pharo-contributor

now provides two videos demonstrating how this tool can be used as an 
alternative to easily contribute to latest Pharo 7


VIDEO 1
https://www.youtube.com/watch?v=z4PWGxihdxU

VIDEO 2
https://www.youtube.com/watch?v=24ERozCePME

Re: [Pharo-dev] who redefined the #balloonBackgroundColor for dark theme?

[Torsten Bergmann]

Hi Hilaire,

why not make a custom "DrGeoDarkTheme" as
 
 - a subclass of "PharoDarkTheme" (in Pharo 7) 
 - or "Pharo3DarkTheme" (when still in Pharo 6, note this class is deprecated 
in Pharo 7)
 
there you can overwrite the appropriate methods for your personal styled 
colors. 

I guess this was the idea for the theming class hierarchy and to my knowledge 
custom theming
is used by Moose and others.

Attached is an example and you can easily switch to it using

   DrGeoDarkTheme beCurrent 

in your playground, startup.st, the settings or other to get the yellow tooltip 
back.

You can add new custom colors for Dr.Geo to this class, ... - so no dictionary 
needed.
Or if you like the dictionary approach you can provide it in your subclass for 
Dr. Geo.

Bye
T.




DrGeoTheme.cs
Description: Binary data

Re: [Pharo-dev] GT Playground Print It Popup unreadeable

[Torsten Bergmann]

H Sven


Sven Van Caekenberghe wrote:
>In the very latest Pharo 7 using the Dark Theme (with the recent changed 
>Tooltip), the intermediate Popup shown when doing Print It in a GT Playground 
>is unreadable:

see my reply in 
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-May/271654.html
which also will fix this issue.

Thx
T.
 
 

Re: [Pharo-dev] who redefined the #balloonBackgroundColor for dark theme?

[Torsten Bergmann]

Peter wrote:
>Finally, consider the following test: In a dark room, only monitor with pharo 
>and dark theme is producing light. Now a large popup with yellow background 
>appears... did your eyes squint? can you suddenly see >the other side of the 
>room? :)

Instead of hypothetical tests I tend to code in a light room and rather use the 
practical approach of
fixing an issue when it appears or when I get blamed for it :P

All details and a proposed solution are summarized in new issue: 
https://pharo.fogbugz.com/f/cases/21856/
which 
 - will not hardcode the balloon background color (as it was before the 
introduction of #21809)
   by using a lighter version of the darkBaseColor for balloonBackgroundColor 
in DarkTheme
 - nonetheless exactly restores the actual color values of the dark theme as 
before the introduction of issue #21809
 - still allows to define a tooltips text color on the graphics theme as it was 
the goal in #21809

Also a new PR is awaiting a review: 
https://github.com/pharo-project/pharo/pull/1320

Thx
T.

Re: [Pharo-dev] who redefined the #balloonBackgroundColor for dark theme?

[Torsten Bergmann]

This came from https://pharo.fogbugz.com/f/cases/21809

- the original changeset came from Hilaire
- Stef wanted to do prepare the PR
- I actually did the PR using the CS from Hilaire
- it was reviewed and merged by Marcus
- now Sven likes it too ;)

So you have to blame half of the community :P

For me it is showing yellow with black (not white) text which seems OK.
But I usually work with the light theme and might be biased.

No problem from my side to have a look at other tools with a dark theme
(like VisualStudio, IntelliJ, Eclipse or other) to find a better color 
combination.

Bye
T.

> Gesendet: Dienstag, 08. Mai 2018 um 15:30 Uhr
> Von: "Esteban Lorenzano" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] who redefined the #balloonBackgroundColor for dark theme?
>
> really?
> 
> 
> 
> git says guilty was Torsten :P
> anyway… that’s an awful color for background on dark. 
> Why nobody realised it before? I’m using a variant of the dark theme myself 
> and I just realised now… what changed?
> 
> Esteban

Re: [Pharo-dev] 'Contribute a fix to Pharo' for new Iceberg ?

[Torsten Bergmann]

Hi Sven

if you like you can also use my "https://github.com/astares/pharo-contributor; 
- at least 
on Ubuntu (where I wrote, tested and use it)

- just clone the project
- use "download.sh" to download latest P7 automatically and started, it will 
also load a contribution 
  help book I did where all is explained

- For a quick start usually you just have to go to the very last help page of 
the appearing help tool and click 
  on 

CPTCloneTool run

  to automagically download and update you fork (after giving your Github 
username)

Then you can contribute as usual by having a branch for a bug number in Iceberg 
and so on. 

Side note:
=
Currently new Iceberg still has some trouble:
 - one has to discard the changes on Fuel (as there are none) after the 
automatic synch of the tool
 - one has to "LGitLibrary initialize" when one reopens a saved image (see 
start.sh), otherwise VM will crash
I already notfied Esteban.

For questions on my workflow with the tool: I'm usually available on Discord.

I'm sure there will also be an update of the official contribution tutorial and 
AFAIK Esteban
want to do some screencasts. 

Thx
T.


> Gesendet: Montag, 23. April 2018 um 11:38 Uhr
> Von: "Sven Van Caekenberghe" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] 'Contribute a fix to Pharo' for new Iceberg ?
>
> Hi,
> 
> I got the new Iceberg working on the latest Pharo 7 (used it to commit 
> something to P3) - authentication should be OK then I guess. It feels much 
> better.
> 
> I would like to try contributing to Pharo again.
> 
> Has https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo 
> been updated for the new Iceberg ?
> 
> Have things become simpler ?
> 
> I also forgot the easy/short git command to bring my fork up to date (if I 
> have to do this myself).
> 
> Sven
> 
> 
> 

Re: [Pharo-dev] Do we kill the catalog?

[Torsten Bergmann]

Hi Stef,

do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog 
- without having 
or proposing a suitable alternative yet. If you want to route the thread to 
talking about "idiots" 
and "assholes" you go offtopic and I guess I have nothing more to contribute to 
the discussion.

If it was not clear from my writing: I only expressed my wish that we should 
better improve it 
instead of killing it. That's all.

Because anytime we have a better idea we get more disruptive in what we provide 
... and this 
leads to the unfortunate situation:

 - that we replace our own stuff with newer ones again and again (which can but 
must not be good
   as things get more diverse and complicated over time)
 - that users have to know how things historically have been progressed to find 
its way 
   through Pharo (including the terms and tools we use)

I would not see this as a rant - but rather a true effect we can spot on many 
places in our 
ecosystem already. 

Long story short: I would vote for the "fix" if the sole other option is to 
"remove".  

Bye
T.


> Gesendet: Samstag, 21. April 2018 um 15:31 Uhr
> Von: "Stephane Ducasse" <stepharo.s...@gmail.com>
> An: "Pharo Development List" <pharo-dev@lists.pharo.org>
> Betreff: Re: [Pharo-dev] Do we kill the catalog?
>
> Torsten
> 
> Sometimes you should relax. Because if you remember I pushed the
> catalog (in fact I love it and we need a much more powerful one)
>  and I even improved it. I made it better to automatically add MC 
> repositories.
> Of course Thierry is exagerating.
> 
> Now we should fix or remove it. Simple no?
> 
> Now you can rant in your corner thinking that I'm asshole.
> This is ok for me.
> 
> Stef
> 
> On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <asta...@gmx.de> wrote:
> > Even there is no learning from the past - it's deja vu all over again...
> >
> >
> >> Gesendet: Freitag, 20. April 2018 um 08:53 Uhr
> >> Von: "Stephane Ducasse" <stepharo.s...@gmail.com>
> >> An: "Pharo Development List" <pharo-dev@lists.pharo.org>
> >> Betreff: Re: [Pharo-dev] Do we kill the catalog?
> >>
> >> Hi torsten
> >>
> >> the wise shows the moon, the idiot sees his finger.
> >>
> >> Stef
> >>
> >>
> >> On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <asta...@gmx.de> wrote:
> >> > Now today you had loading trouble with Smacc from Catalog ... and now 
> >> > directly want to
> >> > kill catalog. Wow!
> >> >
> >> > Sometimes I have the impression that our community tries to reinvent 
> >> > itself each day
> >> > doing it differently (but not only better) instead of extending, 
> >> > improving and supporting
> >> > what we have have done before. Which sometimes is good ... but not 
> >> > always.
> >> >
> >> > Thx
> >> > T.
> >> >
> >> >> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
> >> >> Von: "Stephane Ducasse" <stepharo.s...@gmail.com>
> >> >> An: "Pharo Development List" <pharo-dev@lists.pharo.org>
> >> >> Betreff: [Pharo-dev] Do we kill the catalog?
> >> >>
> >> >> Hi guys
> >> >>
> >> >> What do we do with it?
> >> >> What alternatives?
> >> >>
> >> >> Stef
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> 
> 

Re: [Pharo-dev] Do we kill the catalog?

[Torsten Bergmann]

Even there is no learning from the past - it's deja vu all over again...


> Gesendet: Freitag, 20. April 2018 um 08:53 Uhr
> Von: "Stephane Ducasse" <stepharo.s...@gmail.com>
> An: "Pharo Development List" <pharo-dev@lists.pharo.org>
> Betreff: Re: [Pharo-dev] Do we kill the catalog?
>
> Hi torsten
> 
> the wise shows the moon, the idiot sees his finger.
> 
> Stef
> 
> 
> On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <asta...@gmx.de> wrote:
> > Now today you had loading trouble with Smacc from Catalog ... and now 
> > directly want to
> > kill catalog. Wow!
> >
> > Sometimes I have the impression that our community tries to reinvent itself 
> > each day
> > doing it differently (but not only better) instead of extending, improving 
> > and supporting
> > what we have have done before. Which sometimes is good ... but not always.
> >
> > Thx
> > T.
> >
> >> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
> >> Von: "Stephane Ducasse" <stepharo.s...@gmail.com>
> >> An: "Pharo Development List" <pharo-dev@lists.pharo.org>
> >> Betreff: [Pharo-dev] Do we kill the catalog?
> >>
> >> Hi guys
> >>
> >> What do we do with it?
> >> What alternatives?
> >>
> >> Stef
> >>
> >>
> >
> 
> 

Re: [Pharo-dev] Do we kill the catalog?

[Torsten Bergmann]

Now today you had loading trouble with Smacc from Catalog ... and now directly 
want to 
kill catalog. Wow!

Sometimes I have the impression that our community tries to reinvent itself 
each day
doing it differently (but not only better) instead of extending, improving and 
supporting
what we have have done before. Which sometimes is good ... but not always.

Thx
T.

> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
> Von: "Stephane Ducasse" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] Do we kill the catalog?
>
> Hi guys
> 
> What do we do with it?
> What alternatives?
> 
> Stef
> 
> 

[Pharo-dev] Small lint cleanups for Zodiac

[Torsten Bergmann]

Hi Sven,

attached some small lint cleanups for Zodiac as I was not able to commit to 
Zodiac on SThub.
Changes mentioned below. This was done in Pharo 7 but based on latest MCZ's.

Thx
T.

--
Name: Zodiac-Core-TorstenBergmann.48
Author: TorstenBergmann
Time: 4 April 2018, 7:45:15.792684 am
UUID: 2c097b10-6125-0d00-ae7c-de9200a97a05
Ancestors: Zodiac-Core-SvenVanCaekenberghe.47

use common "initialization" category to prevent lint problems in Pharo 7

--
Name: Zodiac-Tests-TorstenBergmann.20
Author: TorstenBergmann
Time: 4 April 2018, 7:51:47.289684 am
UUID: 54ced027-6125-0d00-ae7d-4b5100a97a05
Ancestors: Zodiac-Tests-SvenVanCaekenberghe.19

add comment for ZdcByteArrayManagerTests
--
Name: Zodiac-Tests-TorstenBergmann.21
Author: TorstenBergmann
Time: 4 April 2018, 8:08:38.372684 am
UUID: 4cb51464-6125-0d00-ae7e-d1a000a97a05
Ancestors: Zodiac-Tests-TorstenBergmann.20

Lint cleanup: use #assert:equals: and remove unnecessary nots



Zodiac-Core-TorstenBergmann.48.mcz
Description: Binary data


Zodiac-Tests-TorstenBergmann.20.mcz
Description: Binary data


Zodiac-Tests-TorstenBergmann.21.mcz
Description: Binary data

Re: [Pharo-dev] DigitalSignatureAlgorithm and dsa.test.out

[Torsten Bergmann]

Answering myself: this file is generated from another method in the same class.

Not obvious - we should clean this up  ...


> In DigitalSignatureAlgorithm>>testExamplesFromDisk uses a file called
> "dsa.test.out" 
> 
> Do we have it somewhere (to turn the method into a real test) or can 
> we just delete the method ...
> 
> Thx
> T.
> 
> 

[Pharo-dev] DigitalSignatureAlgorithm and dsa.test.out

[Torsten Bergmann]

In DigitalSignatureAlgorithm>>testExamplesFromDisk uses a file called
"dsa.test.out" 

Do we have it somewhere (to turn the method into a real test) or can 
we just delete the method ...

Thx
T.

Re: [Pharo-dev] Seaside loading broken in Pharo 7

[Torsten Bergmann]

> Normally loading #bleedingEdge of Zn, but I have to see if the very, very 
> latest changes are in.
> 
> You need Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58 or newer.

Already trapped in Git/Monticello problems: 

1. In latest Pharo 7 Build 70715 I open Monticello browser and then I add

MCHttpRepository
location: 'http://mc.stfx.eu/ZincHTTPComponents'
user: ''
password: ''

   Now try to browse the contents of the repo I already get a DNU because 
   IceProxyMCVersionInfo returns nil when asked for a #versionNumber leading
   to other trouble.


2. Now I try to load what you suggested with a script:

  Gofer it
  url: 'http://mc.stfx.eu/ZincHTTPComponents';
  package: 'Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58';
 load

   which fails as this version of the package is not there

   Currently http://mc.stfx.eu/ZincHTTPComponents only goes up to 

   Zinc-Character-Encoding-Core-SvenVanCaekenberghe.39

and the 39 up to 58 are missing.

So where is Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58 or newer 
versions hosted???

Thanks 
T.

 

Re: [Pharo-dev] Seaside loading broken in Pharo 7

[Torsten Bergmann]

Is there already a fix available, any reference issue?
@Sven: can you tell us about the status/steps?

 
 

Gesendet: Dienstag, 13. März 2018 um 21:26 Uhr
Von: "Cyril Ferlicot" <cyril.ferli...@gmail.com>
An: "Pharo Development List" <pharo-dev@lists.pharo.org>
Betreff: Re: [Pharo-dev] Seaside loading broken in Pharo 7


 

On mar. 13 mars 2018 at 21:11, Torsten Bergmann <asta...@gmx.de> wrote:

Hi Pharo-dev (CC Seaside-dev)

the Seaside PR on discussions for Pharo 7 supprt on

https://github.com/SeasideSt/Seaside/pull/979

says one should use

Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:master/repository';
 load.

to load Seaside in Pharo 7 (which was from around 7th of February)

I today tried with latest 70694 fresh Pharo image but after a while I get many
walkback debuggers with #setToEnd, isReadOnly and #closed not implemented
on ZnCharacterReadWriteStream

while it is loading "Zinc-Character-Encoding-Core-SvenVanCaekenberghe.56"

If I remember correctly I was able to load it in P7 two weeks ago - so something
broke it meanwhile.

Any ideas?

 

Hi! This is because of a really recent change and Sven is working on it. 

 



Bye
T.
 


--

Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Torsten Bergmann]

Additional portable versions would be nice too (based on a simple ZIP) instead 
of only the installable apps

Re: [Pharo-dev] [Request for comment] Hermes package

[Torsten Bergmann]

Thanks for the quick feedback. Here is the associated issue:  https://pharo.fogbugz.com/f/cases/21442/Add-class-comments-to-Hermes-package

tagged with "Must fix" ;)

Thanks
T.

 



Gesendet: Mittwoch, 28. Februar 2018 um 11:02 Uhr
Von: "teso...@gmail.com" <teso...@gmail.com>
An: "Pharo Development List" <pharo-dev@lists.pharo.org>
Betreff: Re: [Pharo-dev] [Request for comment] Hermes package


Hi, 
    Sorry I have missed the comments. I will add them as soon as possible. 

You are right we should improve the quality, thanks for checking it and remembering everybody.

 

Cheers,


 
On Wed, Feb 28, 2018 at 10:42 AM, Torsten Bergmann <asta...@gmx.de> wrote:

... to all participating authors of the Hermes package:

PLEASE COMMENT YOUR CLASSES SO WE CAN CLEAN UP AND PREPARE A
POLISHED PHARO 7 RELEASE

So many uncommented classes in there today...

We can do better and we should. I dont ask for detailed documentation
but a single comment why the class is there or what it should care
about is often already enough.

If you have time to write code then you also have the time to write
a simple class comment!

So please do you homework (which is a general request to authors
of other packages as well)

Bye
T.
 

 

 
--

Pablo Tesone.
teso...@gmail.com

[Pharo-dev] [Request for comment] Hermes package

[Torsten Bergmann]

... to all participating authors of the Hermes package:

PLEASE COMMENT YOUR CLASSES SO WE CAN CLEAN UP AND PREPARE A 
POLISHED PHARO 7 RELEASE

So many uncommented classes in there today...

We can do better and we should. I dont ask for detailed documentation
but a single comment why the class is there or what it should care
about is often already enough.

If you have time to write code then you also have the time to write 
a simple class comment! 

So please do you homework (which is a general request to authors
of other packages as well)

Bye
T.

Re: [Pharo-dev] Simplified AST "Suggestions" menu definitions

[Torsten Bergmann]

Added to: http://wiki.astares.com/pharo/607


> Gesendet: Montag, 26. Februar 2018 um 08:17 Uhr
> Von: "Marcus Denker" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] Simplified AST "Suggestions" menu definitions
>
> 
> 
> > On 25 Feb 2018, at 21:30, Stephane Ducasse  wrote:
> > 
> > Marcus I thought that the context was about to represent what the
> > tools selected like the class currently selected.
> > You have this information in the AST?
> > 
> The AST as coming from the Parser: no. The AST after name Analysis: yes.
> Which means you actually need the class to do name analysis (“Semantic 
> Analysis”, 
> implemented by OCASTSemanticAnalyzer).
> 
> I think it will be easy:
> 
> -> there is RubSmalltalkCodeMode / RubSmalltalkScriptingMode which models if 
> the editor.
> is editing Doits or Methods (important for parsing!).
> -> RubSmalltalkCodeMode does have an ivar classOrMetaclass already. It is not 
> set by most tools yet, though.
> -> we can easily add there (or in RubSmalltalkEditor) an “ast “ ivar and 
> re-parse at every keystroke.
> 
> So as soon as we make sure that all users of RubSmalltalkCodeMode correctly 
> set the class, this will be all
> very simple.
> 
>   Marcus
>

[Pharo-dev] Cleanup of LDAP for Pharo 6/7

[Torsten Bergmann]

Just as an info: the LDAP packages from 

http://smalltalkhub.com/#!/~PharoExtras/LDAP

had no method categorization and missing class comments and was
not updated since Pharo 4.

I took some minutes today to clean this up and I also added a new 
baseline/version
not loading Zinc (as this is already included) for Pharo 6 and 7.

The latest config is now also in MetaRepoForPharo60 and with that
should be available for catalog tomorrow for easy consumption after the
catalog indexer runs.

Thx
Torsten/astares