[Pharo-dev] Re: [ANN] Pharo Launcher 3.2 released!

[Tim Mackinnon]

Just to add to what others have said - the presentation at Esug on 3.2 was very 
cool. You raised some very interesting use-cases that the command line gives 
(like using $vars to help manage consistent project naming). So thanks for 
pushing on this. 

Tim

On Wed, 10 Jul 2024, at 6:45 PM, Christophe Demarey wrote:
> Hi all,
> 
> Pharo Launcher 3.2 has just been released! It is available from 
> http://pharo.org/download.
> 
> 
> Pharo Launcher now comes with a command-line version that you can use from a 
> terminal!
> You can check the documentation of commands at 
> https://pharo-project.github.io/pharo-launcher/commands-cmd-line/ as well as 
> instructions to make pharo-launcher available on command line: 
> https://pharo-project.github.io/pharo-launcher/installation/.
> This nice feature is now available thanks to the contributions of Axel 
> Marlard, David Bajger and I as well as the support of Damien Pollet for the 
> Clap library.
> 
> New features:
> 
>  • Command Line support
> 
>• all commands available in the UI version of Pharo Launcher are supported
>• new commands
>  • create an image from a Pull Request number (from Pharo repository)
>  • create an image from a build number, a SHA
>  • create an image and import your code from a repository
>  • share easily an image (zip file with the Pharo image, the VM to run it 
> and a launch script)
>  • find easily the Pharo version where a bug was introduced with image 
> *bisect* algorithm
>  • launch an image with a script
>  • list running Pharo processes
>  • When creating an image, the image is now launched automatically
> 
>  • CI moved to Github Actions
> 
> Improvements:
> 
>  • Better Mac Os system menu
>  • Do not try to guess anymore the version of a Pharo image if information 
> not available but rather ask the user
>  • When deleting more than 1 image at a time the message is not clear #594 
> 
> Bug fixes:
> 
>  • Pharo 12.0 build list incomplete #667 
> 
>  • Use "Show" when no image is downloaded yet gives error #570 
>  (thanks to 
> @astares )
>  • Development mode does not close pharoLauncher application #548 
> 
>  • Using "Show in folder" gives DNU #568 
>  (thanks to 
> @astares )
>  • Launcher cannot launch Pharo-4.0 image #585 
> 
> 
> 
> Regards,
> The Pharo team.

[Pharo-dev] Re: Info required for bootstrapping pharo on GNU Guix

[Tim Mackinnon]

While it sounds like a lot of work - if thats your itch I suppose its a good 
test of the work that Stephane mentions. By redoing it in a different 
environment it might iron out any accidental environment dependencies.

Presumably its just the VM you need to bootstrap - as I would view the image as 
being like a Word or PDF document - and would be surprised that they would 
expect you to bootstrap those too?

Good luck - and courage.

Tim

On Tue, 21 May 2024, at 9:47 AM, Nicolas Graves via Pharo-dev wrote:
> On 2024-05-21 09:34, stephane ducasse wrote:
>
>> Hi 
>>
>> Why can’t you use the latest Pharo vm and Pharo12?
>> We worked like mad over the years to get a much better system. 
>> Now why do you need to bootstrap Pharo because you can just use a 
>> bootstrapped image
>> and get pharo working and running?
>
> Guix is not using the FHS filesystem so it would be a mess to try and
> bootstrap from binaries. On top of that, they focus on
> reproducibility. The standard on this end is to try and not use any
> binary code if it's possible to build if from source, and yes, it
> requires working like mad over the years. The website is currently down,
> but there's an article about how they get all 30k packages from only a
> single tiny binary file.
>
> Some of the guys behind Guix are also involved in bootstrappable.org
>
> I understand and share that the current system is much better, it's just
> that to comply with their standard, that's what I have to do.
>
> What I understand from there it that it's feasible: 
> https://x.com/estebanlm/status/1042719107307712514
>
> I'll do the work if feasible, I just can't find the information where I
> should start from, hence my email.
>
> Best,
> Nicolas
>
>>
>> S
>>
>>> On 21 May 2024, at 09:31, Nicolas Graves via Pharo-dev 
>>>  wrote:
>>> 
>>> Hi Pharo community,
>>> 
>>> I'm trying to package pharo in the GNU Guix linux distribution. Since
>>> the distribution is focused on reproducibility and avoids using binary
>>> code when possible, for that I need to reproduce the bootstrapping steps
>>> that are embedded in Pharo. I understand from some developper online
>>> comment that this is possible.
>>> 
>>> I've started to work on this and it seems feasible, at least I get the
>>> dependency loop, what I've some difficulty is to get precisely when it's
>>> possible to get started.
>>> 
>>>  ---
>>>  | v
>>>  pharo VMpharo
>>>  ∧ |
>>>  ---
>>> 
>>> If I'm correct,
>>> - bootstrapping is very clear after version ~7.0.0, and with a proper
>>> build, just follow the distribution numbers in wget's with a cmake
>>> build-system.
>>> - for earlier versions, there's the repository
>>> https://github.com/pharo-project/PharoBootstrap
>>> that seems (git history) to be able to go back to Pharo 30.
>>> - I understand that at some point, Squeak and Pharo used to have the
>>> same VM. I have access to a squeak-vm 4.10.2.2614 in Guix, and I've seen
>>> this is in Pharo's ftp files, so I guess I can start there.
>>> 
>>> What I need:
>>> - Some indication about the first version of Pharo that I'm able to
>>> build purely from squeak-vm, and where to find its source code
>>> (git+version or commit if possible, I seem to only be able to find its
>>> binaries currently in phero's ftp files).
>>> - Any useful information for early bootstrap steps.
>>> 
>>> Some useful information on my side:
>>> - During the build process in Guix, we can't download data, so the
>>> entire bootstrap chain has to be explicited at once, hence the need to
>>> go back to the beginning in this case.
>>> 
>>> Thanks in advance!
>>> 
>>> -- 
>>> Best regards,
>>> Nicolas Graves
>>
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr
>> 06 30 93 66 73
>>
>> "If you knew today was your last day on earth, what would you do 
>> differently? ESPECIALLY if, by doing something different, today might 
>> not be your last day on earth.” Calvin & Hobbes
>>
>>
>>
>>
>>
>
> -- 
> Best regards,
> Nicolas Graves

[Pharo-dev] Re: [Esug-list] [ANN] Soil release v1

[Tim Mackinnon]

That's really exciting news... appreciate you sharing it with the wider 
community (I know when you mentioned its existence a while back I went and 
watched the Esug recordings to get more info, and looked at some of the 
extensive test cases to get a feel on what it looked like - its neat).

Having multiple options for persisting data (from simple Fuel up to Soil and 
Glorp and Gemstone) is very useful.

Tim

On Wed, 24 Apr 2024, at 12:52 PM, Norbert Hartl wrote:
> ...we said at last ESUG that there will be a release soonish but as usual it 
> doesn't go that fast. 
> 
> But now we are very happy to announce that Soil has a first public release 
> v1. So what is soil?
> 
> Soil is an object oriented database in pharo . It is 
> transaction based having ACID transactions. It has binary search capabilities 
> with SkipList and BTree+ indexes. It aims to be a simple yet powerful 
> database making it easy to develop with, easy to debug with, easy to inspect, 
> ...
> 
> More details at https://github.com/ApptiveGrid/Soil
> 
> This release is still considered early stage because 
> 
>  • although in ApptiveGrid there are over 4000 instances of it and there are 
> other users there isn't a wider range of use cases, yet. So it is not fully 
> battle tested. This just as reminder when you start compaining I need 
> somewhere to point my finger to and say "I told you!" ;)
>  • there are few things missing that you might expect like garbage 
> collection, etc.
> 
> So but it is definetely usable and awaiting the brave ones of you to try. 
> 
> Hopy you enjoy it!
> 
> Norbert & Marcus
> ___
> Esug-list mailing list -- esug-l...@lists.esug.org
> To unsubscribe send an email to esug-list-le...@lists.esug.org
> 

[Pharo-dev] Re: "The Classification Model" — New blog post on all: objects all: theTime

[Tim Mackinnon]

By the way - it's a shame there is no rss feed for you blog as I like to use a 
feed reader on my phone to keep up with such things. Not sure what you are 
using, but if you could enable it, that would be coo.

Tim

On Tue, 19 Mar 2024, at 4:30 PM, Tim Mackinnon wrote:
> Hi Koen - is there any particular place you would like us to feedback on the 
> posts? Is here useful, or some other location?
> 
> I like the concepts you are introducing (I need to take to read your PHD - so 
> good to have the link in there) - but the devil is in the detail of course.
> 
> If I have understood correctly - the idea of computed classifications give 
> rise to the flexibility we all crave?  So in my previous comment - when 
> designing a new class and trying to work out its protocol, in particular how 
> to instantiate it vs. update it - its very inconvenient to have to flip 
> between class and instance method definitions - a much flatter view of a 
> Class has both instance AND class methods that I can see together is more 
> efficient to work with in that initial design phase vs later when stabilised 
> the more traditional - a Class name has Class and Instance definition, a 
> Class definition has class methods, an Instance definition has instance 
> methods (apologies if terminology isn't quite right - typing this in a hurry 
> on a break). 
> 
> But does the classification model handle the above? To flatten instance and 
> class methods into a single sorted list (discriminated in some manner - like 
> one being bold or having some prefix) and also allowing you to add to add new 
> items to that list and provide that discrimination sounds like it might not 
> fit that classification model? Or maybe it does? I guess we do currently 
> allow methods to have categories and we can view multiple categories in a 
> list.  I guess I'm curious how it hangs together to model non-trivial 
> examples? And maybe this is the next blog post?
> 
> Thanks for surfacing the ideas.
> 
> Tim
> 
> On Mon, 18 Mar 2024, at 5:51 PM, Koen De Hondt wrote:
>> Dear Pharo users and developers,
>> 
>> Last week I told you about a new blog post that outlined the objectives of 
>> the Atlas browser. It was the first post of a series.
>> If you liked it, I invite you to read the next post 
>> <https://all-objects-all-the-time.st/#/blog/posts/7>. It describes the 
>> Classification Model, which is the foundation of Atlas.
>> 
>> Happy reading!
>> 
>> Ciao,
>> Koen
> 

[Pharo-dev] Re: "The Classification Model" — New blog post on all: objects all: theTime

[Tim Mackinnon]

Hi Koen - is there any particular place you would like us to feedback on the 
posts? Is here useful, or some other location?

I like the concepts you are introducing (I need to take to read your PHD - so 
good to have the link in there) - but the devil is in the detail of course.

If I have understood correctly - the idea of computed classifications give rise 
to the flexibility we all crave?  So in my previous comment - when designing a 
new class and trying to work out its protocol, in particular how to instantiate 
it vs. update it - its very inconvenient to have to flip between class and 
instance method definitions - a much flatter view of a Class has both instance 
AND class methods that I can see together is more efficient to work with in 
that initial design phase vs later when stabilised the more traditional - a 
Class name has Class and Instance definition, a Class definition has class 
methods, an Instance definition has instance methods (apologies if terminology 
isn't quite right - typing this in a hurry on a break). 

But does the classification model handle the above? To flatten instance and 
class methods into a single sorted list (discriminated in some manner - like 
one being bold or having some prefix) and also allowing you to add to add new 
items to that list and provide that discrimination sounds like it might not fit 
that classification model? Or maybe it does? I guess we do currently allow 
methods to have categories and we can view multiple categories in a list.  I 
guess I'm curious how it hangs together to model non-trivial examples? And 
maybe this is the next blog post?

Thanks for surfacing the ideas.

Tim

On Mon, 18 Mar 2024, at 5:51 PM, Koen De Hondt wrote:
> Dear Pharo users and developers,
> 
> Last week I told you about a new blog post that outlined the objectives of 
> the Atlas browser. It was the first post of a series.
> If you liked it, I invite you to read the next post 
> . It describes the 
> Classification Model, which is the foundation of Atlas.
> 
> Happy reading!
> 
> Ciao,
> Koen

[Pharo-dev] Re: "Introducing Atlas" — New blog post on all: objects all: theTime

[Tim Mackinnon]

As browsers are a passion in the Smalltalk world it will be great to read your 
thoughts - as its certainly a hot potato, and we don't seem to have quite 
cracked it so far.

I recall the presentations on Calypso from Pharo days (might have been recorded 
for review if you haven't seen them). I recall being won over at the time (and 
I was hesitant)  - there was lots of flexibility that had been thought about, 
and many useful and tricky browsing patterns were covered - but over time I 
think its proved tricky to work with. In Pharo 11, the browsers don't seem to 
work as well as they should (lots of funny focus issues and loss of context 
that I don't recall in previous version - which I think is more down to 
understanding how it was supposed to work than technical flaws).

It's definitely worth generating conversation and getting some consensus 
otherwise it will be a rise and fall scenario all over again. This said, 
continuing to find a good model that is both flexible and simple is useful.

Tim

p.s. On thing I recall from those Calypso presentations was that the model 
should have let us design browsers where we  have different navigation models  
(e.g. you in theory you could design something where a class has a path to 
methods which are both instance and class so you don't have to have a mode to 
swap between them - something I find distracting when designing the interface 
of a class and trying to figure out how you instantiate/initialize it and you 
want to jump between the 2 view - I just want to see all all the methods in a 
list, differentiated in some way vs. hiding them).

On Sun, 10 Mar 2024, at 5:24 PM, Koen De Hondt wrote:
> Dear Pharo users and developers,
> 
> Some people already know that I am working on a browser for Pharo. With this 
> announcement, I make it official .
> In my latest blog post , 
> I introduce Atlas as an ambitious successor of Calypso. It is the first post 
> in a series.
> 
> Happy reading!
> 
> Ciao,
> Koen

[Pharo-dev] Re: [ANN] success story: ApptiveGrid

[Tim Mackinnon]

Appreciate the great write up - I’d heard mention of Adaptive Grid but hadn’t realised its full extent - wow! It’s a project to inspire us all.Tim On 14 Dec 2023, at 22:42, Sean Glazier  wrote:





That's really great!




Get Outlook for iOS

From: Sven Van Caekenberghe 
Sent: Thursday, December 14, 2023 8:19:06 AM
To: Pharo Development List 
Cc: Pharo users users 
Subject: [Pharo-dev] Re: [ANN] success story: ApptiveGrid
 


Yes, this is a really nice project, the front end as well.

It reminds me a bit of FileMaker, but for the web.

I am hoping you have commercial success with ApptiveGrid !

> On 12 Dec 2023, at 13:02, Norbert Hartl  wrote:
> 
> I wanted to write this for a very long time now…so finally…I’m very proud to announce a new success story: ApptiveGrid
> 
> ApptiveGrid is a SaaS tool to digitalize and automatize business processes.
> 
> On the one hand ApptiveGrid is visual database that enables you to model your database via web frontend. At the same time this model is available via REST API.

> 
> 
> 
> On top of the data model a form creator turns your model into a form that you can send e.g. via email to inquire data from other people…
> 
> 
> 
> On the other hand ApptiveGrid is a workflow system where you can define your work flow in the web frontend and connect to events. These events are either internal (resulting from a change in your data model) or external where you can use web hooks to kick
 of work flows.
> 
> 
> 
> With the combination of both parts ApptiveGrid is able to solve many of modern digital workflows. It enables to make it for low cost and in almost no time which are two pretty good reasons to use it. If you want to use it just visit:
http://www.apptivegrid.de. ApptiveGrid provides a start plan at no cost where most of the functionalities are available. If you have additional needs just write me. For the people in the pharo community I’m sure we can
 provide a bit more on top.
> 
> About the tech stack:
> 
> - The business backend of ApptiveGrid is 100% pharo 
> - It uses https://github.com/svenvc/zinc components for the HTTP frontend

> - and https://github.com/ApptiveGrid/Soil as the persistence solution.

> - Each user has its own database (an empty soil database is 24kb on disk, could be made even approx. 5kb). There are over 3100 databases in the system right now
> - one pharo image holds multiple soil databases open and provides memory caching for the objects
> - routing of requests is done with haproxy connection persistence
> - the web frontend is made with Vue.js and a pharo library that we transpile to JS with PharoJS
> 
> If you are interested you can also watch my ESUG videos at 
https://www.youtube.com/@esugboard. All talks in the last 2 years were about ApptiveGrid
> 
> If you have question, don’t hesitate to ask, I’m happy to answer!
> 
> Norbert
> 

[Pharo-dev] Re: # This week (40/2023) on the Pharo Issue Tracker

[Tim Mackinnon]

I don't look in depth every week - but gosh there are always some great items 
in the list when you do look. Its all the little details the make you smile - 
removing old usages etc. This is how you fix a big system bit by bit - its very 
inspirational and a good example for the day jobs as well. Thanks everyone... 
people do appreciate it.

Tim 

On Fri, 6 Oct 2023, at 1:45 PM, Marcus Denker wrote:
> # Fixes
>
> - Fix intersection of dictionaries #14812
>   https://github.com/pharo-project/pharo/pull/14812
>   
> - Fix announcements during class creation #14816
>   https://github.com/pharo-project/pharo/pull/14816
>   
> - Prevent SystemDictionary key to be something else than symbols #14813
>   https://github.com/pharo-project/pharo/pull/14813
>   
> - Kernel: Fix CompiledMethod>>#propertyAt:ifPresent: #14823
>   https://github.com/pharo-project/pharo/pull/14823
>   
> - Allow defining methods from class pane again #14824
>   https://github.com/pharo-project/pharo/pull/14824
>   
> - 14864-Recompiling-a-method-when-a-tool-looks-at-it-DNU-name-is-nil #14865
>   https://github.com/pharo-project/pharo/pull/14865
>   
> - speedup-runtimeUndeclaredRead #14873
>   https://github.com/pharo-project/pharo/pull/14873
>   
> - Fix Deprecation for methods that use #runtimeUndeclaredRead #14872
>   https://github.com/pharo-project/pharo/pull/14872
>   
> # Features
>
> - There is #workDatesDo:, but no #workDates #14820
>   https://github.com/pharo-project/pharo/pull/14820
>
>
> # Graphics
>
> - Factor out methods for allocating and drawing the cache canvas from 
> HandMorph onto FormCanvas #14890
>   https://github.com/pharo-project/pharo/pull/14890
>
> - Factor out methods for saving and restoring patches from HandMorph 
> onto Canvas #14841
>   https://github.com/pharo-project/pharo/pull/14841
>   
> - Remove some unused methods from the Canvas hierarchy #14855
>   https://github.com/pharo-project/pharo/pull/14855
>   
> - Defer change list update to avoid a race condition #14853
>   https://github.com/pharo-project/pharo/pull/14853
>
> # Package cleanup
>
> - Remove usage of #category: in trait tests #14877
>   https://github.com/pharo-project/pharo/pull/14877
>   
> - RPackage: Simplify tests and fix bug in package removal #14875
>   https://github.com/pharo-project/pharo/pull/14875
>   
> - RPackage: Introduce UndefinedPackageTag #14876
>   https://github.com/pharo-project/pharo/pull/14876
>
> - RPackage: Revert #packageName #14825
>   https://github.com/pharo-project/pharo/pull/14825
>   
> - Monticello: Simplify classRemoved: #14857
>   https://github.com/pharo-project/pharo/pull/14857
>   
> - RPackage: remove private import method #14879
>   https://github.com/pharo-project/pharo/pull/14879
>
> - Change set should not depend on ClassRecategorized #14880
>   https://github.com/pharo-project/pharo/pull/14880
>   
> - RPackage: ClassRepackaged announcement should know the package tags #14881
>   https://github.com/pharo-project/pharo/pull/14881
>
> - RPackage: New step at cleaning tests #14883
>   https://github.com/pharo-project/pharo/pull/14883
>
> # Refactoring Engine
>
>
> - Refactor: reusing transformations where possible #14862
>   https://github.com/pharo-project/pharo/pull/14862
>
> - Refactoring: Get away from class definition #14852
>   https://github.com/pharo-project/pharo/pull/14852
>
> - Refactoring: Remove controllers #14828
>   https://github.com/pharo-project/pharo/pull/14828
>   
> - fixes #14715: RBNamespace >> classNamed: should convert strings to 
> symbols #14831
>   https://github.com/pharo-project/pharo/pull/14831
>
> - [Refactoring engine] 2023 09 26 enh remove instance variable2 #14790
>   https://github.com/pharo-project/pharo/pull/14790
>   
> - Refactoring engine: Cleaning up #14834
>   https://github.com/pharo-project/pharo/pull/14834
>
> # Documentation 
>
> - Adding a #reflection: pragma on reflective methods #14821
>   https://github.com/pharo-project/pharo/pull/14821
>   
> - Bootstrap: Add logs to early steps of the bootstrap #14861
>   https://github.com/pharo-project/pharo/pull/14861
>   
> # Tools
>
> - Debugger protocol cleaning #590
>   https://github.com/pharo-spec/NewTools/pull/590
>   
> - Debugger class side cleaning #594
>   https://github.com/pharo-spec/NewTools/pull/594
>   
> - Scrolling to selection when selecting path to the receiver class in 
> the meta browser (Fix for the meta browser in the inspector) #597
>   https://github.com/pharo-spec/NewTools/pull/597
>   
> - StVersionBrowserPresenter : no need to use #instanceSideParentName 
> (which is Ring1 specific) #596
>   https://github.com/pharo-spec/NewTools/pull/596
>   
> - fix #testStackTablePackagesLabels: use correct DoIt selector #595
>   

[Pharo-dev] Re: Fun with CleanBlocks or: Speeding up Dictionary>>#at:

[Tim Mackinnon]

I love these little discussions/examples that you share... things you take for 
granted have subtle impacts that are worth reasoning about. Whenever I read 
them, it definitely improves my understanding and makes me a better programmer. 
Thanks Markus.

Tim

On Fri, 19 May 2023, at 12:01 PM, Marcus Denker wrote:
> Dictionary lookup is used a lot. Let's look at Dictionary>>#at:
>
>
> at: key
>   "Answer the value associated with the key."
>   ^ self at: key ifAbsent: [self errorKeyNotFound: key]
>
>
> The method looks simple and at a first glance, there are no obvious problems.
>
> But if we look at it again, we see that for every execution of #at:, 
> the block [self errorKeyNotFound: key]
> has to be created. The method stores a CompiledBlock in the literals, 
> and a bytecode "create block" creates 
> the block:
>
> ```
> (Dictionary>>#at:) symbolic 
>
> "'41 <4C> self
> 42 <40> pushTemp: 0
> 43 <40> pushTemp: 0
> 44  fullClosure:a CompiledBlock: [self errorKeyNotFound: key] 
> NumCopied: 1
> 47  send: at:ifAbsent:
> 48 <5C> returnTop'"
> ```
>
> This happens at *every* execution of #at:, even though the block that 
> we spend time to create will never
> be executed at runtime (outside of real errors).
>
> If you look at the rest of the code path of #at: in a Dictionary, it is 
> carefully written to avoid block creation
> by using optimized contructs (ifTrue: and friends).
>
> Could clean blocks help? Clean blocks are blocks that only use data 
> that the compiler knows at compile time,
> thus we can create a CleanBlockClosure (which has the CompiledBlock) 
> and store *that* as a Literal.
>
> This then would mean that we could just use as fast pushLiteral: to 
> push the block, no creation at runtime needed.
>
> Clean blocks are not yet enabled by default, but we can use a compiler 
> option pragma to enable them just for this
> method:
>
> ```
>   
> ```
>
> The problem is that the block references both "self" and the key to be 
> able to show a nice error message.
> Referencing either one make the block not clean. 
>
> Could we change the block to be clean? I guess we could not refer self 
> and inline the method #errorKeyNotFound: 
> (knowing the instance is not that important for logging the error in 
> production, for example). But we do want 
> to know the key that is not found, it really simplifies debugging 
> especially if you have to look at log files.
> 
> If we closely look at the block: we know a bit more about it and how it 
> is used. We know that if it gets evaluated, 
> that evaluation will *always* happen with the homeContext of the block 
> on the stack, as it is will always be #at:ifAbsent: 
> that evaluates that block.
> 
> And in that case, there is a trick that we can do: we can use 
> reflection to read the needed values via the stack.
> 
> You might not be aware, but the debugger needs some quite interesting 
> features from the reflective layer of the system to provide
> the user experience that you take for granted (and that feels trivial). 
> Imagine a block like that:
>
> ```
> tt
>
>   | temp1 temp2 |
>   temp1 := 1.
>   temp2 := 2.
>
>   self class methods do: [ :each | self halt. each with: temp1 ].
>   ^ temp2
> ```
>
>
> The block does not reference temp2, so it actually is created as a 
> block that does not know temp2 at all. temp2 is not accessibe from the 
> block or it's context.
> Yet, when debugging, you want to just be able to write temp2 in the 
> block and eval it (without saving the method), as *if* you would access
> the temp in this block and recompile, the compiler would compile a 
> different block that would know temp2.
>
> So the reflective API of Context (and the infrastructure of reading 
> Variables reflectively), is build in a way that #readVariableNamed: 
> will 
> use the stack to find the value of temps that are not available in the 
> block context, but could be available if they would be referenced 
> statically.
>
> And if you think about it, we have just a case like that here, in 
> reverse: if we would use #readVariableNamed: on the context to read the 
> argument,
> the compiler would not see a read of "key", thus compile a block that 
> does not have that temp available. And if we then read "self" via 
> thisContext, too,
> the compiler sees a block that it can compile as a clean block:
>
>
> at: key
>   "Answer the value associated with the key."
>   
>   
>   
>   ^ self at: key ifAbsent: [
>   
>   "this block is never executed, yet we pay runtime cost to 
> create it 
> if it is a full block.
>   We use instead the reflective API to read the argument and 
> receiver 
> via the stack, making
>   the block clean.
>   
>   We enable cleanBlocks for this method by setting 
> optionCleanBlockClosure as it is not yet
>   enabled by default"
>   
>   KeyNotFound signalFor: (thisContext 

[Pharo-dev] Re: This week (9/2023) on the Pharo Issue Tracker

[Tim Mackinnon]

While I'm not able to commit time to help due to personal commitments taking 
all my spare time at the moment - it does make me smile reading the list of 
improvements and the fact the people care about this stuff. Big thanks to all 
of you!

Tim

On Fri, 3 Mar 2023, at 10:51 AM, Marcus Denker wrote:
> We merged 58 PRs this week:
>
>
> Compiler
> 
>
> - Improve faulty parsing of byte array literal (alternative version) #12818
>   https://github.com/pharo-project/pharo/pull/12818
>   
> - NumberParser: kill requestor #12835
>   https://github.com/pharo-project/pharo/pull/12835
>   
> - Add RBToken>>isSpecial: to simplify parsing code #12836
>   https://github.com/pharo-project/pharo/pull/12836
>   
> - Clean some parsing code #12861
>   https://github.com/pharo-project/pharo/pull/12861
>   
> - Improve scanning: escape comments #12857
>   https://github.com/pharo-project/pharo/pull/12857
>
> - Hook for custom syntaxhighlight #12594
>   https://github.com/pharo-project/pharo/pull/12594
>   
> - Improve faulty parsing: generalize code snippets #12847
>   https://github.com/pharo-project/pharo/pull/12847
>   
> - Improve faulty parsing: rename content as contents (a s was missing) #12854
>   https://github.com/pharo-project/pharo/pull/12854
>   
> - 
> 12858-CopiedLocalVariable-answers-false-to-isTemporaryVariable-even-when-it-is
>  
> #12869
>   https://github.com/pharo-project/pharo/pull/12869
>   
> - HotFix. Restore RBScanner>>#parseErrorNode: #12875
>   https://github.com/pharo-project/pharo/pull/12875
>   
> - Do not stack RBUnfinishedStatementErrorNode #12873
>   https://github.com/pharo-project/pharo/pull/12873
>   
> - EFFormatter use parenthesis on error nodes if some were present #12872
>   https://github.com/pharo-project/pharo/pull/12872
>   
> - RBCodeSnippet nice overview of error messages #12871
>   https://github.com/pharo-project/pharo/pull/12871
>   
> - Rewrite some error messages to follow the style Foo expected #12874
>   https://github.com/pharo-project/pharo/pull/12874
>   
> - Improve faulty parsing on variables #12868
>   https://github.com/pharo-project/pharo/pull/12868
>   
> - Improve faulty parsing of methods #12879
>   https://github.com/pharo-project/pharo/pull/12879
>   
> - Improve faulty parsing by testing unreachable code #12893
>   https://github.com/pharo-project/pharo/pull/12893
>   
> - Improve faulty parsing on chars (and primitive arrays) #12891
>   https://github.com/pharo-project/pharo/pull/12891
>
> Fixes
> =
>
> - Update matchesTypes to fix DNU in matchesTypes #12611
>   https://github.com/pharo-project/pharo/pull/12611
>
> - Fix float comparision with precision and start to test Math-Operation… 
> #12615
>   https://github.com/pharo-project/pharo/pull/12615
>   
> - Refactoring TDebugger class>>#handlesContext: to 
> TDebugger>>#handlesDebugSession: #12833
>   https://github.com/pharo-project/pharo/pull/12833
>   
> - New try at not hardcoding Metacello Attributes #12511
>   https://github.com/pharo-project/pharo/pull/12511
>   
> - Fix TPrintTests rotten green tests #12846
>   https://github.com/pharo-project/pharo/pull/12846
>
> - Use MethodClassifier protocol for new methods instead of the selected 
> protocol #12882
>   https://github.com/pharo-project/pharo/pull/12882
>   
> - Do not ask the user a method protocol first but instead try to auto 
> classify the method and only ask the user if auto classification failed 
> #470
>   https://github.com/pharo-spec/NewTools/pull/470
>   
> - Fix #10929 Graphic UI selection glitch with selected text on large 
> screens #12863
>   https://github.com/pharo-project/pharo/pull/12863
>   
> - Fix #12459 : text selection drag and drop problem. #12460
>   https://github.com/pharo-project/pharo/pull/12460
>   
> - Fixing debugger inspector that wasn't updating when the debugger 
> entered a new optimized scope #472
>   https://github.com/pharo-spec/NewTools/pull/472
>
> - Prevent recursive retries on createIcebergRepositoryWithFallbackFor:url: 
> #1673
>   https://github.com/pharo-vcs/iceberg/pull/1673
>   
> - Fixes: Committing with empty description can lead to problems #1681 #1682
>   https://github.com/pharo-vcs/iceberg/pull/1682
>
> External Package
> ===
>
> - Update the version of graph algos to use the latest one #12851
>   https://github.com/pharo-project/pharo/pull/12851
>   
> - Updating Tonel version #12865
>   https://github.com/pharo-project/pharo/pull/12865
>   
> - Sync ston #12829
>   https://github.com/pharo-project/pharo/pull/12829
>   
> - Microdown-RichTextComposer is now managed outside #12890
>   https://github.com/pharo-project/pharo/pull/12890
>   
>
> CI 
> ===
>
> - Make all PRs to run in the latest VM #12605
>   

[Pharo-dev] Re: This week (46/2022) on the Pharo Issue Tracker

[Tim Mackinnon]

Wow - thats even neater... all done with our normal tools - on the fly. So 
cool. Not sure many environments/languages can reason about things in this way.

Worthy of a blog post for the wider world I would say - as this kind of stuff 
should be on more people's radars.

Thanks again for all this kind of work. It would be so easy to just continue to 
think the job was done 20 years ago, where in fact we've only scratched the 
surface as our understanding of effective software development has improved.

Tim

On Fri, 18 Nov 2022, at 10:19 AM, Marcus Denker wrote:
> 
> 
> > On 18 Nov 2022, at 08:15, Marcus Denker  wrote:
> > 
> > We merged 18 PRs
> > 
> > Lots of improvements related to  BlockClosures this week. 
> > 
> > First some helper methods on the AST:
> > - #hasNonLocalReturn: check if there is a non-local return
> > - #isConstant: Blocks of the kind [#justSomeLiteral]
> > - #constantValue: return that literal (and nil for empty [] )
> > - #numArgs for RBBlockNode, as we have already for BlockClosure  "[:a | ] 
> > sourceNode numArgs”
> > 
> 
> Some numbers:
> 
> "there are lots of blocks"
> allBlocks := Smalltalk globals allMethods flatCollect: [:meth | meth ast 
> blockNodes ].
> allBlocks size. "100140"
> 
> "but many are compiled inline (eg argunments of #ifTrue:)"
> currentFullBlocks := allBlocks select: [:blockNode | blockNode isInlined not].
> currentFullBlocks size. "45193"
> 
> "What we could compile as CleanBlockClosure"
> cleanBlocks := currentFullBlocks select: [:blockNode | blockNode isClean].
> cleanBlocks size. "11090"
> 
> "many clean blocks are actually constant"
> constantBlocks := cleanBlocks select: [:blockNode | blockNode isConstant].
> constantBlocks size. "3200"
> 
> "FullBlocks that need the outerContext to return"
> fullBocksWithReturn := currentFullBlocks select: [ :each  | each 
> hasNonLocalReturn ].
> fullBocksWithReturn size “3816”
> 
> We can inspect the collections and then use the inspector to browse the code 
> (with the block
> that you look at hightlighted), to get a feel where these are used, e.g. for 
> constant:
> 
> 
> 
> 

[Pharo-dev] Re: This week (46/2022) on the Pharo Issue Tracker

[Tim Mackinnon]

The attention to detail on these cleanups to make everything symmetrical is 
very nice - cool work.

Tim

On Fri, 18 Nov 2022, at 7:15 AM, Marcus Denker wrote:
> We merged 18 PRs
>
> Lots of improvements related to  BlockClosures this week. 
>
> First some helper methods on the AST:
> - #hasNonLocalReturn: check if there is a non-local return
> - #isConstant: Blocks of the kind [#justSomeLiteral]
> - #constantValue: return that literal (and nil for empty [] )
> - #numArgs for RBBlockNode, as we have already for BlockClosure  "[:a | 
> ] sourceNode numArgs"
>
> Some improvements for isClean:
> - unify between AST and BlockClosure
> - more tests
> - inlined blocks can be clean, important as it is recursive: [true 
> ifTrue: []] should be clean
> - cleanup code in CleanBlock, receiver is known to be nil
>
> Compiler support for ConstantBlockClosure:
> - We can specialize clean blocks of the kind [#justSomeLiteral] to 
> execute faster
> - add ConstantBlockClosure, add compiler support, active when compiling 
> with clean blocks enabled
>
> Compiler support for full block without outer context:
> - we only need the outerContext for non-local returns. 
> - add support to IRBuilder for full blocks without outer context
> - implement compiler support (option #optionBlockClosureOptionalOuter, 
> false for now)
>
> Quick return for Blocks:
> - Compile quickreturn for CompiledBlock, just like CompiledMethod (e.g. 
> for [^1]).
> - speeds up execution a little (but of course not creation)
>
> Block Closures
> ==
>
> - AST: add a recursive #hasNonLocalReturn and #isConstant #11882
>   https://github.com/pharo-project/pharo/pull/11882
>   
> - add #numArgs to RBBlockNode #11902
>   https://github.com/pharo-project/pharo/pull/11902
>
> - CleanBlock cleanup code: there should be no receiver ivar #11884
>   https://github.com/pharo-project/pharo/pull/11884
>   
> - 11881-RBBlockNodeisClean-takes-every-optimized-block-to-be-not-clean #11890
>   https://github.com/pharo-project/pharo/pull/11890
>   
> - 1883-CleanBlockChecker-does-not-recurse-into-the-blocks #11900
>   https://github.com/pharo-project/pharo/pull/11900
>   
> - ConstantBlockClosure: active when compiling with clean blocks enabled #11894
>   https://github.com/pharo-project/pharo/pull/11894
>   
> - CompiledBlocks: compile quick returns #11907
>   https://github.com/pharo-project/pharo/pull/11907
>
> - IRBuilder: add support for outerContext flag for Closure creation #11905
>   https://github.com/pharo-project/pharo/pull/11905
>   
> - 11911-Compiler-add-compiler-option-for-outerContextNeeded #11917
>   https://github.com/pharo-project/pharo/pull/11917
>   
>
>
> Fixes
> =
>
> - Register-as-basicInspector #431
>   https://github.com/pharo-spec/NewTools/pull/431
>   
> - 11803 return value of inspect should be the receiver and not a sp 
> window presenter #11886
>   https://github.com/pharo-project/pharo/pull/11886
>   
> - Fixes #429, VersionBrowser: left pane empty #430
>   https://github.com/pharo-spec/NewTools/pull/430
>
> - Turn off ReLongMethodsRule for test methods #11892
>   https://github.com/pharo-project/pharo/pull/11892
>   
> - ClassParser: Implement #asSlot to return a correct Slot instances for 
> complex slots #11898
>   https://github.com/pharo-project/pharo/pull/11898
>   
> - Fixes #11802 - Adds full consistency checks to class Time #11891
>   https://github.com/pharo-project/pharo/pull/11891
>   
> - Fixing to correctly get the VM for running the tests #11897
>   https://github.com/pharo-project/pharo/pull/11897
>   
> - Fixes #429, VersionBrowser: left pane empty #430
>   https://github.com/pharo-spec/NewTools/pull/430
>   
> Cleanup
> ===
> - 11810-FT2Handle-classstartUp-compiled-code-on-image-startup #11811
>   https://github.com/pharo-project/pharo/pull/11811
>  
>   
>   
> Comments
> =
>
> - fixing comments in package Regex #11888
>   https://github.com/pharo-project/pharo/pull/11888

[Pharo-dev] Re: Omnibase/Monibase repository removal

[Tim Mackinnon]

That is unfortunate - is there any way to get the original author to change his 
mind (I'm guessing they reached out in a huff - which is understandable if this 
came up unexpectedly)?

It seems unfortunate effort to rewrite something, and from an Omnibase 
perspective, I can't imagine there is sustainable money to be made from future 
sales of the product (in a world of so many databases more widely available), 
however offering services on top (which I'm sure the original author is in the 
best place to do) would seem like a better aim instead of cutting your nose off 
to spite your face.

Of course he is the one that can ultimately make the call, but worth double 
checking I would say.

Tim

On Mon, 8 Aug 2022, at 2:18 PM, Norbert Hartl wrote:
> To all Omnibase and Monibase users. 
> 
> It turned out that neither of those are open source. The author of the 
> database contacted me clarifying the situation that he has the copyright and 
> never released something open source. This means that I will remove the 
> Omnibase repositories in few weeks from 
> 
> https://github.com/ApptiveGrid/MoniBase
> 
> and 
> 
> https://github.com/pharo-nosql/OmniBase
> 
> I'm very sorry about that but someone just took the code 9 years before, 
> copied it on github and put illegally an MIT license to the repository. We 
> only want free software in our repositories and hence the above will go away.
> 
> As we see it essential to have a good OO database in pharo we will see how 
> much effort it will be build a small and simple OO database that can replace 
> Omnibase. 
> 
> regards,
> 
> Norbert

[Pharo-dev] Re: Problem installing pharo in my university

[Tim Mackinnon]

I note you can report false positives to Kaspersky if the exe is not 
contaminated - https://support.kaspersky.com/viruses/answers/1870

Tim

On Wed, 15 Jun 2022, at 12:00 AM, stephane ducasse wrote:
> hello Jannik
>
> I hope that you are getting well. We can only support such installation :)
>
> Now I do not think that we ship the exe with a virus but we will check. 
> The problem is that Pharo VM produces assembly code and probably that 
> Kaspersky is thinking that this is a virus. 
>
> I think that we will have to have a way to assess whether an 
> installation is exactly the one we 
> deliver. 
>
> S
>
>> On 13 Jun 2022, at 03:03, Jannik Laval  wrote:
>> 
>> Dear Pharoers,
>> 
>> I want to install the stable version of pharo on all the computers of my 
>> academic component, but the IT Service has a problem with Kaspersky Security.
>> It identifies a Trojan…
>> 
>> Do you know this problem ? And how to install Pharo ?
>> 
>> Best regards, 
>> 

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

[Tim Mackinnon]

Wow - I hadn't realised this was so imminent... very impressive - thanks for 
everyones contributions on this - its inspiring, the the turnaround time but 
also the kind of work you have picked off.

Tim

On Tue, 5 Apr 2022, at 11:39 AM, Esteban Lorenzano wrote:
> Dear Pharo users and dynamic language lovers: 
> 
> We have released Pharo version 10  !
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> 
> 
> Pharo 10 was a short iteration where we focused mainly on stability and 
> enhancement of the environment :
> 
>  * Massive system cleanup
>  ** gained speed
>* removed dead code
>* removed old/deprecated frameworks (Glamour, GTTools, Spec1)
>  * All Remaining tools written using the deprecated frameworks have been 
> rewritten: Dependency Analyser, Critique Browser, and many other small 
> utilities.
>  * Modularisation has made a leap, creating correct baselines (project 
> descriptions) for many internal systems, making possible the work and 
> deployment of minimal images.
>  * Removing support for the old Bytecode sets and embedded blocks simplified 
> the compiler and language core.
>  * As a result, our image size has been reduced by 10% (from 66MB to 58MB)
>  * The VM has also improved in several areas: better async I/O support, 
> socket handling, FFI ABI,  
> Even being a short iteration, we have closed a massive amount of issues: 
> around 600 issues and 700 pull requests. A more extended changelog can be 
> found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo100ChangeLogs.md.
> 
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 10 image was contributed 
> by more than 80 people.
> 
> Pharo is more than code. It is an exciting project involving a great 
> community. 
> 
> We thank all the contributors to this release:
> 
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Alejandra Cossio, Aless Hosry, 
> Alexandre Bergel, Aliaksei Syrel, Alistair Grant, Arturo Zambrano, Asbathou 
> Biyalou-Sama, Axel Marlard, Bastien Degardins, Ben Coman, Bernardo Contreras, 
> Bernhard Pieber, Carlo Teixeira, Carlos Lopez, Carolina Hernandez, Christophe 
> Demarey, Clotilde Toullec, Connor Skennerton, Cyril Ferlicot, Dave Mason, 
> David Wickes, Denis Kudriashov, Eric Gade, Erik Stel, Esteban Lorenzano, 
> Evelyn Cusi Lopez, Ezequiel R. Aguerre, Gabriel Omar Cotelli, Geraldine 
> Galindo, Giovanni Corriga, Guille Polito, Himanshu, Jan Bliznicenko, Jaromir 
> Matas, Kasper Østerbye, Kausthub Thekke Madathil, Konrad Hinsen, Kurt 
> Kilpela, Luz Paz, Marco Rimoldi, Marcus Denker, Martín Dias, Massimo 
> Nocentini, Max Leske, Maximilian-ignacio Willembrinck Santander, Miguel 
> Campero, Milton Mamani Torres, Nahuel Palumbo, Norbert Hartl, Norm Green, 
> Nour Djihan, Noury Bouraqadi, Oleksandr Zaitsev, Pablo Sánchez Rodríguez, 
> Pablo Tesone, Pavel Krivanek, Pierre Misse-Chanabier, Quentin Ducasse, 
> Raffaello Giulietti, Rakshit, Renaud de Villemeur, Rob Sayers, Roland 
> Bernard, Ronie Salgado, Santiago Bragagnolo, Sean DeNigris, Sebastian Jordan 
> Montt, Soufyane Labsari, Stephan Eggermont, Steven Costiou, Stéphane Ducasse, 
> Sven Van Caekenberghe, Theo Rogliano, Thomas Dupriez, Théo Lanord, Torsten 
> Bergmann, Vincent Blondeau.
>  
> 
> (If you contributed to Pharo 10 development in any way and we missed your 
> name, please send us an email and we will add you).
> 
> Enjoy!
> 
> The Pharo Team
> 
> Discover Pharo: https://pharo.org/features
> 
> Try Pharo: http://pharo.org/download
> 
> Learn Pharo: http://pharo.org/documentation

[Pharo-dev] Re: This week (10/2022) on the Pharo Issue Tracker

[Tim Mackinnon]

This is really good stuff - we don't say thank you to everyone enough.

Its easy to add new cool stuff... to safely fix ongoing history, and learn from 
old mistakes to create better tested solutions is really hard - and a testament 
to the durability and hard work of this community.

Wow.

Tim

On Fri, 11 Mar 2022, at 7:15 AM, Marcus Denker wrote:
> We merged 3 PRs and fixed 4 Issue tracker entries.
>
> Especially  #10972 is important: with this the bug that lead to an 
> overly huge image size is fixed.
>
> Now one can actually see that Pharo10 is smaller than Pharo9 due to:
>
>   - code cleanup: removal of dead code, simplifications, cleanups
>   - sharing of literals across all methods as part of the image build
>   - first small improvement of size of the data structures of the code 
> (related to Protocol)
>   (much more possible here, but it has to wait for Pharo11)
>
>
> There are more PRs ready for Pharo10 that just need a review to be merged: 
>   https://github.com/pharo-project/pharo/pulls 
>
>
>
> Fixes
> 
>
> 10667-Installed-breakpoints-not-shown-in-UI-after-AST-cache-reset-during-image-saving
>  
> #10962
>   https://github.com/pharo-project/pharo/pull/10962
>   
> ensure no literal is kept pinned in memory when building an image #10972
>   https://github.com/pharo-project/pharo/pull/10972
>   
> Extend class comment of Dictionary #10973
>   https://github.com/pharo-project/pharo/pull/10973

[Pharo-dev] Re: Hardening Zinc's Core HTTP Server

[Tim Mackinnon]

Agreed - that has been a great test and appreciate all the effort that went 
into this.

Tim

On Thu, 2 Dec 2021, at 1:11 PM, Guillermo Polito wrote:
> Thanks Sven, 51 days uptime is super encouraging :)
> 
>> El 30 nov 2021, a las 17:45, Sven Van Caekenberghe  escribió:
>> 
>> Hi,
>> 
>>> On 29 Oct 2021, at 20:42, Sven Van Caekenberghe  wrote:
>>> 
>>> Here is yet another update:
>>> 
>>> The instances
>>> 
>>> - On Amazon AWS: http://34.245.183.130:1701
>>> 
>>> - On Microsoft Azure: http://51.137.72.94:8080
>>> 
>>> have now been running for 18+ days.
>>> 
>>> Having observed the overall amounts of critical resources inside the Pharo 
>>> images, things look good.
>>> 
>>> Seaside WASSession cleanup goes slowly but does work over time.
>>> 
>>> Eventually I will stop at least the Azure instance because it costs me 
>>> personal money.
>> 
>> I disabled the Microsoft Azure VM instance at http://51.137.72.94:8080 to 
>> save money. Final uptime was 51 days.
>> 
>> Here is the final screenshot:
>> 
>> 
>> 
>> I'll leave the Amazon AWS VM instance at http://34.245.183.130:1701 up for 
>> now.
>> 
>> Sven
>> 
 On 11 Oct 2021, at 19:37, Sven Van Caekenberghe  wrote:
 
 Here is an update on the status of both instances.
 
 A couple of people tried fiddling with invalid input which did result in 
 exceptions, but everything was handled correctly so that the server kept 
 on functioning.
 
 There were no spurious crashes.
 
 There was one attack by Levente Uzonyi that was successful though. 
 
 He used the fact that Seaside sessions are long lived (cached for a 
 certain time) combined with the fact that the Reddit.st 
  app kept one GLORP database connection through P3 open 
 to PostgreSQL and fired off a small denial of service (DOS) attack. 
 Eventually either the VM ran out of space in the ExternalSemaphoreTable, 
 making Socket creation, either for database connections or for handling 
 new HTTP request impossible or the database's own connection limit was 
 reached. At that point the HTTP server or the Pharo VM stopped functioning.
 
 Although Levente used a sequential number of requests, a concurrent number 
 of request could cause similar problems (related, but differently).
 
 In looking at what he reported it also became clear that I accidentally 
 left a debugging exception handler active, which is not good in a 
 production image.
 
 Both instances are now redeployed with the following changes:
 
 - the Reddit.st  code was changed to not keep the 
 database connection open all the time, but instead connect/disconnect per 
 request. this might be a bit slower, but it conserves resources much 
 better and solves the original issue Levente reported
 
 https://github.com/svenvc/Reddit/commit/f2e0a0dc00b9cbb68cfa4fb007906365ae66ab1b
 
 - a new feature was added to Zinc HTTP Components' 
 ZnManagingMultiThreadedServer (the default) to enforce a maximum number of 
 concurrent connections being allowed (the limit is 32 by default, but 
 changeable if you know what you are doing). when the limit is reached, 503 
 Service Unavailable responses are sent to the excess clients and the 
 connection is closed. this should help protect against concurrent 
 connection DOS attacks
 
 https://github.com/svenvc/zinc/commit/ac0f06e74e7ab129610c466cb1d7ea9533d29b4c
 
 - the deploy script was changed to use the more primitive WAErrorHandler
 
 https://github.com/svenvc/Reddit/commit/874b631e6dc0c04c8c0b687ef770d00540d282df
 
 Thanks again to Levente for taking the time to try an attack and for 
 reporting it clearly.
 
 Sven
 
> On 29 Sep 2021, at 17:10, Sven Van Caekenberghe  wrote:
> 
> Both instances have been up for 5 days now, looking for more testers.
> 
>> On 23 Sep 2021, at 17:03, Sven Van Caekenberghe  wrote:
>> 
>> Hi,
>> 
>> Zinc HTTP Components [https://github.com/svenvc/zinc] has been a part of 
>> Pharo since version 1.3 (2011). It is an open-source framework to deal 
>> with the HTTP networking protocol, modelling all aspects involved. It 
>> also offers both client and server functionality.
>> 
>> The reliability of the code base has improved steadily over the years, 
>> thanks to virtually all Pharo developers using it, directly or 
>> indirectly. Over the summer a number of issues that popped up after 
>> Pharo 9 was released were resolved.
>> 
>> The robustness of the core HTTP server is one important aspect. To put 
>> this quality further to the test, I deployed two servers with the same 
>> demo Seaside application, Reddit.st, open to the internet, without any 
>> further protections.
>> 
>> - On Amazon AWS: http://34.245.183.130:1701
>> 
>> 

[Pharo-dev] Re: Hardening Zinc's Core HTTP Server

[Tim Mackinnon]

Hey Sven - really appreciate your thorough approach to this, and it’s been 
interesting seeing the results (I did try a few script injection attempts but 
didn’t get up to running burp suite on it, which  I may try it while you have 
the instances).

Kudos to Levente for taking a more reasoned approach and using inside 
knowledge… this community is awesome!

Tim

> On 29 Oct 2021, at 19:42, Sven Van Caekenberghe  wrote:
> 
> Here is yet another update:
> 
> The instances
> 
> - On Amazon AWS: http://34.245.183.130:1701
> 
> - On Microsoft Azure: http://51.137.72.94:8080
> 
> have now been running for 18+ days.
> 
> Having observed the overall amounts of critical resources inside the Pharo 
> images, things look good.
> 
> Seaside WASSession cleanup goes slowly but does work over time.
> 
> Eventually I will stop at least the Azure instance because it costs me 
> personal money.
> 
>> On 11 Oct 2021, at 19:37, Sven Van Caekenberghe  wrote:
>> 
>> Here is an update on the status of both instances.
>> 
>> A couple of people tried fiddling with invalid input which did result in 
>> exceptions, but everything was handled correctly so that the server kept on 
>> functioning.
>> 
>> There were no spurious crashes.
>> 
>> There was one attack by Levente Uzonyi that was successful though. 
>> 
>> He used the fact that Seaside sessions are long lived (cached for a certain 
>> time) combined with the fact that the Reddit.st app kept one GLORP database 
>> connection through P3 open to PostgreSQL and fired off a small denial of 
>> service (DOS) attack. Eventually either the VM ran out of space in the 
>> ExternalSemaphoreTable, making Socket creation, either for database 
>> connections or for handling new HTTP request impossible or the database's 
>> own connection limit was reached. At that point the HTTP server or the Pharo 
>> VM stopped functioning.
>> 
>> Although Levente used a sequential number of requests, a concurrent number 
>> of request could cause similar problems (related, but differently).
>> 
>> In looking at what he reported it also became clear that I accidentally left 
>> a debugging exception handler active, which is not good in a production 
>> image.
>> 
>> Both instances are now redeployed with the following changes:
>> 
>> - the Reddit.st code was changed to not keep the database connection open 
>> all the time, but instead connect/disconnect per request. this might be a 
>> bit slower, but it conserves resources much better and solves the original 
>> issue Levente reported
>> 
>> https://github.com/svenvc/Reddit/commit/f2e0a0dc00b9cbb68cfa4fb007906365ae66ab1b
>> 
>> - a new feature was added to Zinc HTTP Components' 
>> ZnManagingMultiThreadedServer (the default) to enforce a maximum number of 
>> concurrent connections being allowed (the limit is 32 by default, but 
>> changeable if you know what you are doing). when the limit is reached, 503 
>> Service Unavailable responses are sent to the excess clients and the 
>> connection is closed. this should help protect against concurrent connection 
>> DOS attacks
>> 
>> https://github.com/svenvc/zinc/commit/ac0f06e74e7ab129610c466cb1d7ea9533d29b4c
>> 
>> - the deploy script was changed to use the more primitive WAErrorHandler
>> 
>> https://github.com/svenvc/Reddit/commit/874b631e6dc0c04c8c0b687ef770d00540d282df
>> 
>> Thanks again to Levente for taking the time to try an attack and for 
>> reporting it clearly.
>> 
>> Sven
>> 
 On 29 Sep 2021, at 17:10, Sven Van Caekenberghe  wrote:
>>> 
>>> Both instances have been up for 5 days now, looking for more testers.
>>> 
 On 23 Sep 2021, at 17:03, Sven Van Caekenberghe  wrote:
 
 Hi,
 
 Zinc HTTP Components [https://github.com/svenvc/zinc] has been a part of 
 Pharo since version 1.3 (2011). It is an open-source framework to deal 
 with the HTTP networking protocol, modelling all aspects involved. It also 
 offers both client and server functionality.
 
 The reliability of the code base has improved steadily over the years, 
 thanks to virtually all Pharo developers using it, directly or indirectly. 
 Over the summer a number of issues that popped up after Pharo 9 was 
 released were resolved.
 
 The robustness of the core HTTP server is one important aspect. To put 
 this quality further to the test, I deployed two servers with the same 
 demo Seaside application, Reddit.st, open to the internet, without any 
 further protections.
 
 - On Amazon AWS: http://34.245.183.130:1701
 
 - On Microsoft Azure: http://51.137.72.94:8080
 
 The application's source code can be found at 
 [https://github.com/svenvc/Reddit]. For the technically curious there are 
 also deploy instructions at 
 [https://github.com/svenvc/Reddit/blob/main/DEPLOY.md]. The demo app 
 itself is described in an older article 
 [https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740].
  

[Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming

[Tim Mackinnon]

Maybe it’s worth putting something in an faq - that we support the intent of 
the master to main naming convention, but that as we are a small community 
trying to improve many aspects of 50 years of development, this one had to 
unfortunately take a back seat for the moment while we simplify other things to 
make this an easier change?


Tim

> On 19 Jul 2021, at 12:26, stephane ducasse  wrote:
> 
> Sven 
> 
> From that perspective this master to main change will cost us a lot of 
> problem. 
> I decided to continue to configure all my repositories to use master and I 
> will do it for any repository that is related to 
> pharo and that people may use. Just to remove such kind of friction. 
> I would encourage people to do the same like that we do not have to think.
> 
> S
> 
>> On 12 Jul 2021, at 14:32, Sven Van Caekenberghe  wrote:
>> 
>> Hi,
>> 
>> For new GitHub projects the default branch is now main instead of master.
>> 
>> There is however code in Metacello / Iceberg / ... that tries a number of 
>> options if no branch is specified, but it is not yet aware of this change.
>> 
>> Specifically:
>> 
>> This does not work 
>> 
>> ./pharo reddit.image metacello install github://svenvc/Reddit 
>> BaselineOfReddit
>> 
>> instead you have to say
>> 
>> ./pharo reddit.image metacello install github://svenvc/Reddit:main/ 
>> BaselineOfReddit
>> 
>> It took me half an hour to figure this out ;-)
>> 
>> Sven
>> 

[Pharo-dev] Re: Serious NetNameResolver regression

[Tim Mackinnon]

You guys are awesome - such a great community.

> On 16 Jul 2021, at 12:18, teso...@gmail.com wrote:
> 
> I have updated the VMs, the issue should be resolved now.
> 
> On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito  > wrote:
> Hi all,
> 
> it seems we need a new VM release.
> The issue seems fixed since ~6 months ago
> 
> https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce104d8f38d60242fa1cc2bb
>  
> 
> 
> Pablo is updating the stable VMs just in this moment.
> 
> G
> 
> > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe  > > escribió:
> > 
> > Anyway, for now, I added guards:
> > 
> > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
> >  
> > 
> > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
> >  
> > 
> > 
> > but the core problem remains.
> > 
> >> On 15 Jul 2021, at 21:35, Gabriel Cotelli  >> > wrote:
> >> 
> >> You're right Sven. The code in the image looks exactly the same betwen 
> >> Pharo 8 and 9 but the behavior is different. 
> >> 
> >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe  >> > wrote:
> >> 
> >> 
> >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli  >>> > wrote:
> >>> 
> >>> Just doing 
> >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu 
> >>> ';primNameLookupResult
> >>> produces the bogus result. And both methods only call primitives in the 
> >>> SocketPlugin. So I think that no image code is responsible for the 
> >>> behavior change.
> >> 
> >> I don't know, but your example is not good. You have to wait else the 
> >> result is always 0.0.0.0
> >> 
> >> Pharo 7
> >> 
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu 
> >> '; waitForCompletionUntil: 5 
> >> 
> >> false (signal exception)
> >> 
> >> Pharo 9
> >> 
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu 
> >> '; waitForCompletionUntil: 5
> >> 
> >> true (bogus 0.0.0.0 result)
> >> 
> >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe  >>> > wrote:
> >>> Hi,
> >>> 
> >>> It seems that we have a serious NetNameResolver regression: instead of 
> >>> signalling an exception, a bogus value is returned.
> >>> 
> >>> Pharo 7:
> >>> 
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu 
> >>> ' timeout: 10 ] on: NameLookupFailure do: [ 
> >>> :exception | exception ]. 
> >>> 
> >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu 
> >>> '"
> >>> 
> >>> Pharo 9:
> >>> 
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu 
> >>> ' timeout: 10 ] on: NameLookupFailure do: [ 
> >>> :exception | exception ]. 
> >>> 
> >>> "0.0.0.0"
> >>> 
> >>> This is bad. What is even worse is that the following kills your image 
> >>> without leaving any trace (on macOS):
> >>> 
> >>> ZnClient new get: 'http://unknown-stfx.eu '.
> >>> 
> >>> Because it tries to connect to 0.0.0.0
> >>> 
> >>> On linux, at least there is a backtrace:
> >>> 
> >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
> >>> NeoConsole 
> >>> Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 
> >>> Bit)
> >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu 
> >>> ' timeout: 10.
> >>> 
> >>> 0.0.0.0
> >>> pharo> ZnClient new get: 'http://unknown-stfx.eu 
> >>> '.
> >>> 
> >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80 
> >>> [ConnectionTimedOut signal: 'Cannot connect to '
> >>>, (NetNameResolver 
> >>> stringFromAddress: hostAddress) , ':' , port asString] in 
> >>> Socket>>connectTo:port:waitForConnectionFor:
> >>>Receiver: a Socket[unconnected]
> >>>Arguments and temporary variables: 
> >>>hostAddress:0.0.0.0
> >>>port:   80
> >>>timeout:30
> >>>Receiver's instance variables: 
> >>>semaphore:  a Semaphore()
> >>>socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 
> >>> 0]
> >>>readSemaphore:  a Semaphore()
> >>>writeSemaphore: a Semaphore()
> >>> 
> >>> Socket>>waitForConnectionFor:ifTimedOut:
> >>> Socket>>connectTo:port:waitForConnectionFor:
> >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
> >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
> >>> ZdcSocketStream class(ZdcSimpleSocketStream 
> >>> 

[Pharo-dev] Re: PharoJ now available for Pharo10

[Tim Mackinnon]

Indeed - me too, very elaborate...

> On 1 Apr 2021, at 18:52, Noury Bouraqadi  wrote:
> 
> Thank you Guille, Pavel, Torsten, Esteban. You really made me laugh :-)
> 
> On Apr 1 2021, at 7:34 pm, Noury Bouraqadi  wrote:
> Esteban,
> 
> The pharo10 branch of PharoJS is really on GitHub. We are "only" missing 
> Pharo 10 ;-)
> 
> Happy Easter Fools !
> 
> On Apr 1 2021, at 1:48 pm, Esteban Lorenzano  wrote:
> that's nice... specially taking into account that Pharo10 does not yet exits 
> :P
> 
> Esteban
> 
> On Apr 1 2021, at 1:38 pm, Noury Bouraqadi  wrote:
> Hi everyone,
> 
> We continue to make progress during our weekly coding sessions. We are glad 
> to announce that this week we made a huge leap forward. Now PharoJS is 
> available for Pharo 10. To install it, run the following script in a Pharo 10 
> playground
> 
> Metacello new
>   baseline: 'PharoJS';
>   repository: 'github://PharoJS/PharoJS:pharo10';
>   load

[Pharo-dev] Re: Progress Report -> Refactoring Project - ( February 1 - 5 )

[Tim Mackinnon]

I never thought of that implication - if ivars are proper objects (is that now 
applied?) would this issue go away (an ivar would just get a new parent)?

This is a very interesting problem, as its a type of transaction, and I never 
though of it that way - its easy to think of it as just dumb code - but in 
effect it isn’t.

Tim

On Fri, 12 Feb 2021, at 4:30 PM, Sean P. DeNigris wrote:
> Wonderful to have progress on this important topic - thank you!
> 
> Sorry I haven't been following closely (maybe you addressed it already), but
> pushing up instance variables has a dangerous limitation - instances lose
> any data held in that var. I guess it's because it's deleted from the
> subclass prior to adding to the superclass to avoid duplicating. One
> solution would be to add a var to the superclass with a mangled name, copy
> the data for all instances, remove the var from the subclass, and then
> rename the mangled var.
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

[Pharo-dev] Re: Progress Report -> Refactoring Project - ( January 4 - 8 )

[Tim Mackinnon]

Hi Evelyn  - I’m glad your making progress on the refactorings - they were very 
unloved - to the point I had mostly stopped using them as they were either 
broken or didn’t work right. Given refactoring was basically invented in 
Smalltalk we had got into a bad place in the Pharo IDE so I am so pleased to 
see this getting sorted - and hopefully we can get back to a position where 
ours work as well as those in IntelliJ or Eclipse.

On this note - I haven’t noticed whether there is some work to add decent 
keystroke shortcuts to the most important ones so that you do them quickly. I 
am equally hopeful … that its a bit easier for us to write some of our own as 
there are some higher level ones that I would like to try creating (but gave up 
on as it wasn’t particularly obvious how to do it). The mention of refactoring2 
sounds promising.

Anyway - just wanted to add a big thumbs up.

Tim

On Mon, 11 Jan 2021, at 3:09 AM, EVELYN CUSI LOPEZ wrote:
> Hello everyone. 
> 
> Last week I did these tasks:
> 
> - Fix PR of "extract method and occurrences" refactoring 
> (https://github.com/pharo-project/pharo/pull/8193).
> - Fix "replace senders of message by another message" refactoring, the 
> modification is for replace in all classes or only in owner class, this can 
> be scale to replace in determinated classes 
> (https://github.com/pharo-project/pharo/pull/8314).
> - Divide coupled logic between commands, views and refactorings (to remove 
> NautilusRefactoring class).
> - Review how to fix Undo Refactoring issue.
> 
> Tasks for this week:
> 
> - Fix undo refactoring issue.
> - Migrate extract method to refactoring2.
> - Review how migrate all refactoring commands to commander2 now only works in 
> source code context.
> - Fix rename protocol issue 
> (https://github.com/pharo-project/pharo/issues/4461).
> - Fix add argument issue (https://github.com/pharo-project/pharo/issues/5852).
> 
> Cheers,
> Evelyn

[Pharo-dev] Re: Super nice parser improvements soon available

[Tim Mackinnon]

That is awesome work - I love you guys for continuing to improve this stuff! 
It’s inspiring...

Tim

> On 3 Oct 2020, at 10:24, Stéphane Ducasse  wrote:
> 
> 
> 
>> In the last week I’ve worked on doing several enhances to the parser
>> 
>> https://github.com/pharo-project/pharo/pull/7411
>> 
>> Besides several refactorings and cleanups, major changes include:
>> 
>>  - we are able to correctly detect unfinished statements (missing dots)
>>  - we are able to correctly detect unreachable statements (like a statement 
>> after a return statement)
>> 
>> And we still continue parsing. This makes that the faulty parser used for 
>> syntax highlighting and other much more precise, and several of my touches 
>> also fix some of the exceptions found while typing (that were due to wrong 
>> behaviours on the parser).
>> 
>> Also I did a small iteration on top of the “syntax feedback” so it’s less 
>> noisy. We can remove it at any time (that’s just removing a configuration). 
>> But I’d like more feedback before :)
>> 
>> To see the improvements
>> 
>> Pharo 8
>> 
>> 
>> 
>> Pharo9 previous to these changes
>> 
>> 
>> 
>> Pharo9 with these changes
>> 
>> 
>> 
>> 
>> Now, I’ll not deny this is still perfectible, as everything, but we can do 
>> another iteration on top :)
>> 
>> Guille
>> ___
>> Lse-consortium mailing list
>> lse-consort...@lists.gforge.inria.fr
>> https://lists.gforge.inria.fr/mailman/listinfo/lse-consortium
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / 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] Robust Functionality vs. Minimalism (was "Microdown ?")

[Tim Mackinnon]

Nice answer Norbert - I agree with the sentiment.

On Mon, 3 Aug 2020, at 9:01 AM, Norbert Hartl wrote:
> Sean,
> 
> > Am 01.08.2020 um 20:23 schrieb Sean P. DeNigris :
> > 
> > I wonder whether/how-best to apply our principle of minimalism when it
> > applies to areas of the system that, while critical, seem inherently
> > non-minimalist e.g. test harnesses, documentation, etc. 
> > 
> > I thought a lot about this when trying to document and refactor SDL. The
> > lack 
> > of a mock library in core was a big barrier to understanding the 
> > interactions between SDL objects. Maybe I'm being naive, but I feel like if 
> > someone wants a minimal image, they're not going to want to load SUnit or 
> > rich text documentation *at all*, so I don't see the risk-benefit of 
> > crippling these features. 
> > 
> > This also applies to Pillar/Microdown. While *any* rich text comments are an
> > exciting development, I'd like to understand the benefit of Microdown vs.
> > full Pillar syntax. 
> > Presumably the primary benefit is the size of the codebase. Any other
> > reasons?
> > A few other questions about the "rich text doc" roadmap: 
> > 1. Could/will this be extended to method comments? That would be really 
> > cool 
> > :) 
> > 2. How close are we for someone to use full Pillar syntax in class comments 
> > in their own library? Any plans to make this possible? 
> > NB. I originally posted a version of this on an older thread about Pillar
> > but and I'm assuming it may have gotten lost in that limited context.
> > 
> The discussion about markup is a long one we keep doing for years. I 
> personally don't like the pillar syntax too much and I don't see a big 
> reason to keep it. On the other hand markdown is the de facto standard 
> of simple formatting things. It is true that it is hard to parse 
> because the syntax is not well thought.The point being positive about 
> markdown is that it reads well in raw/ascii form and can be parsed into 
> a document model to enable rich text variants like HTML, PDF, etc. 
> And it plays well with the minimalist approach. Because markdown is 
> readable in its raw form it can be used without all of the rich text 
> rendering code loaded. So the goal is to have a pleasant approach to 
> documentation for your big development image. You can make a small 
> image where you can still read the class documentation in its raw form. 
> In a minimalist image you might even strip down class comments to save 
> space, so it's not an issue here. These three levels are the ones I see.
> 
> For the markdown in method comments. This is something I think about 
> since a while. There is still something like the first comment as 
> separation to the rest. For doing a whole class documentation this 
> could be a low hanging fruit as a convention to start. You can use 
> microdown in method comments, too. And that's (again) because it reads 
> well in raw format. After that we have to learn. Especially to 
> understand that the AST and a document model are just two different 
> form of trees that express something about the method. If we find a 
> good way to interleave those trees and can have a rich text component 
> that is rendered nicely with the code it encloses we are a big step 
> nearer to explained code which reversed means executable documentation. 
> 
> Norbert
> > 
> > 
> > -
> > Cheers,
> > Sean
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> > 
> 
> 
>

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

[Tim Mackinnon]


Hi - a bit late to reply on this one, but I did try Jekyl years ago, it was ok 
but over time frustrating to use and difficult to make the pipeline 
understandable ...

I looked at Hugo and a few others but ended up going with Metalsmith (a JS 
static generator). I liked the plugable pipeline model of it, but cursed the 
state of Js tools (a few years ago) .

I’ve been meaning for ages to reimplement it in Smalltalk with a nice oo 
composite pipeline model and an easy way to debug and visualise what is going 
when getting your template right.

Combine this with the new headless image and it should easily plug into netlify 
.

Tim

>> On 23 May 2020, at 21:41, Cédrick Béler  wrote:
> 
> Hi Esteban,
> 
>> This comes really on time for me, I decided to rewrite to small sites I have 
>> using Jekyll, and as read all their tutorials I thought even of having a 
>> Jekyllst variation, that uses the Jekyll directories and other conventions, 
>> but uses Smalltalk as its engine. Of course this is far reached given my 
>> real availability these days, that's lower than usual.
> 
> Cool anyway if that’s something that interest you too. What do you think of 
> https://gohugo.io ?
> 
> Themes are pretty cool https://themes.gohugo.io 
> 
>> 
>> However I'd like to be part of conversations around this, and eventually 
>> contribute to it, because I already started playing with Jekyll (and Gatsby 
>> as well).
> 
> Perfect :)
> 
> This is not urgent but I need to put 2 websites online for September (simple 
> ones). For now, I’m trying around. Summer will be perfect for me to work on 
> such project.
> 
> Cheers,
> 
> Cédrick
> 
>> 
>> Regards,
>> 
>> 
>> Esteban A. Maringolo
>> 
>> 
>>> On Sat, May 23, 2020 at 10:15 AM Cédrick Béler  wrote:
>>> 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 
>>> 
>>> 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)
>>> 
>>> 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) 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 

Re: [Pharo-dev] Difficulty to use Iceberg

[Tim Mackinnon]

Hi Jan - if I’ve understood you correctly, I think this is the same issue you 
would get with a readme.md file in the root of your project, as iceberg only 
deals with its repository tree and nothing else (which has been queried in the 
past - but it’s a design decision for now,  we’ve been told).

To workaround this, checkout your project into a separate directory for the C 
part, and pull push independently from pull push in Pharo part (eg, just 
pretend you are different users collaborating on the same project). It works, 
but remember to do the pull - to catchup when you have done something in the 
other world.

Tim

Sent from my iPhone

> On 22 Sep 2019, at 09:15, Jan Vrany  wrote:
> 
> Hi, 
> 
> I'm experiencing difficulties (code loss, even) when trying to 
> commit code using Iceberg. 
> 
> I have a project with consist of some Pharo code and some
> C++ code. Both parts kind of depend on each other. 
> 
> Imagine I start from commit A
> 
> --- A
> 
> and build and open Pharo image. Then I do some work in
> Pharo and commit, leaving me at B:
> 
> --- A --- B
> 
> Now I need to make some changes to the C++ code, say C & D:
> 
> --- A --- B --- C --- D
> 
> And work little more on C++ but do not commit (therefore I have
> modified C++ files and/or staged changes). Now imagine I need to
> do more changes in Pharo image and commit (should be commit E)
> 
> Now there's the problem. Pharo image thinks it is still at commit B
> and starts complaining about image being out if sync. 
> 
> What is the correct workflow to end up with:
> 
> --- A --- B --- C --- D --- E
> 
> !!! AND !!! with my local modifications to C++ code preserved
> in working copy? I'd be nice to preserve staged changes too,
> but I'd be OK to unstage all changes if necessary.
> 
> Any suggestions? 
> 
> Best, Jan
> 
> 

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

[Tim Mackinnon]

I agree with Ben’s reaction below , however the point that ? ! could be 
repurposed for something if they weren’t special characters is a good one. 
Maybe there are other usages we are missing,  and that’s the point I guess.

Tim

Sent from my iPhone

> On 13 Sep 2019, at 17:41, Ben Coman  wrote:
> 
> 
> 
>> On Wed, 11 Sep 2019 at 15:10, ducasse  wrote:
>> 
>> 
>> > On 11 Sep 2019, at 04:07, James Foster  wrote:
>> > 
>> > Would use of ? and ! in unary/keyword selectors be convention or somehow 
>> > required? If simply convention, then we should start with renaming testing 
>> > methods to be named is* or has*. 
>> >   flag1 := anInteger even.“not good"
> 
> Agreed.  That could "almost" be construed  as converting a 3 to a 2 or 4.
>  
> 
>> >   flag2 := anInteger isEven.  “better"
> 
> Agreed. It reads well.
>  
> 
>> >   flag3 := anInteger even?.   “how much better?”
> 
> For me, this doesn't read as well as flag2, but even though there is some 
> redundancy, for me a combination reads well...
>  flag3a := anInteger isEven?
> Perhaps if "?"==>Boolean was a strong convention then there could be a check 
> when the value is returned rather than when it is used (or would that 
> complicate other things?) 
>  
> 
>> >   flag4 := #(1 2 3) includes?: 2. “how much better?”
> 
> My first impression is "yuck!", but then I think... "maybe" if there was a 
> definite benefit (i.e. optimization) from strong guarantees about the return 
> value being Boolean.
> 
>  
>> 
>> I think that I would use ? mainly for unary message
>> 
>> Now I’m sure that if you look carefully some people use
>> 
>> include
>> for the action
>> includes 
>> for the tests
>> 
>> I took include as an example and this is super not intention revealing. 
>> 
>> >> lineUpBlockBrackets
>> 
>> lineUpBlockBrackets?
>> Now I will rewrite them all as shouldLineUpBlockBrackets or 
>> isLineUpBlockBrackets and to me for unary message ? makes it a lot better.
> 
> btw, some alternatives...  
> doBlockBracketsLineUp   - reads well but "do" is already a loaded word
> areBlockBracketsLinedUp - reads well with the past-tense phrasing
> 
> cheers -ben

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

[Tim Mackinnon]

+1 for #shouldXxx I recall I use it a lot too, and #isXxx where that reads 
better but am struggling for examples.

Tim

Sent from my iPhone

> On 13 Sep 2019, at 02:37, Mariano Martinez Peck  wrote:
> 
> 
> 
>> On Wed, Sep 11, 2019 at 4:10 AM ducasse  wrote:
>> 
>> 
>> > On 11 Sep 2019, at 04:07, James Foster  wrote:
>> > 
>> > Would use of ? and ! in unary/keyword selectors be convention or somehow 
>> > required? If simply convention, then we should start with renaming testing 
>> > methods to be named is* or has*. 
>> >   flag1 := anInteger even.“not good"
>> >   flag2 := anInteger isEven.  “better"
>> >   flag3 := anInteger even?.   “how much better?”
>> >   flag4 := #(1 2 3) includes?: 2. “how much better?”
>> 
>> I think that I would use ? mainly for unary message
>> 
>> Now I’m sure that if you look carefully some people use
>> 
>> include
>> for the action
>> includes 
>> for the tests
>> 
>> I took include as an example and this is super not intention revealing. 
>> 
>> >> lineUpBlockBrackets
>> 
>> lineUpBlockBrackets?
>> Now I will rewrite them all as shouldLineUpBlockBrackets or 
>> isLineUpBlockBrackets and to me for unary message ? makes it a lot better.
>> 
> 
> Hi Stef,
> 
> I have been facing this ambiguity a lot too. And my workaround, most of the 
> times, was also to prefer the "question" method with #should. #is just 
> doesn't sound right in my cases, but #should does sound good in most of them. 
> I would still like to find a better one, but for the moment, in my recent 
> years, I am stuck with #should.
> 
> -- 
> Mariano Martinez Peck
> Email: marianop...@gmail.com
> Twitter: @MartinezPeck
> LinkedIn: www.linkedin.com/in/mariano-martinez-peck
> Blog: https://marianopeck.wordpress.com/

Re: [Pharo-dev] Default line endings while writing to a file stream

[Tim Mackinnon]

It’s a great question with a few follow on’s...

In github I think we can set it to ignore line endings for certain files (I’m 
assuming this is Exercism), although  I’ve noticed it doesn’t seem to always 
work very well (could be the wrong settings thought. We should check we have 
.st set to text in that file.

Similarly however, why is there a critic for line endings in methods? Anyone 
know what the big deal is? I world have thought we don’t care?

Tim

Sent from my iPhone

> On 31 May 2019, at 06:06, Ben Coman  wrote:
> 
> 
> I'm on Windows wanting to write a text file with LF endings.
> The code developed on Linux is thus...
> (destinationDirectory / 'README.md') ensureCreateFile
> writeStreamDo: [ :stream | stream nextPutAll: class comment ]
> 
> and I am stuck with CR line endings.  
> The specific symptom is that it screws `git diff` 
> Here is a simple experiment...
> testfile := 'README.md' asFileReference.
> testfile ensureCreateFile writeStreamDo: [ :stream |
> stream nextPutAll: 'aa
> bb' ].
> testfile binaryReadStream contents at: 3  "==>  Character cr " 
> 
> I think its safe to assume on Linux that will result in "==>  Character lf "
> but can someone please confirm?
> 
> So my issue is that I've got
> #ensureCreateFile - returns a FileReference
> and
> :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream 
> wrapping BinaryFileStream.
> 
> and neither seem to have an easily accessible defaultLineEnding setting.
> Indeed, line endings are not a property of FileReference 
> and Binary & Characters have nothing to do with line endings,
> and questionable if Buffering is related.
> 
> Its more a property of a File, but IIUC that is being deprecated (??)
> 
> MultiByteFileStream has #lineEndConvention:
> but IIUC that also is being deprecated.
> 
> So what is the proper way to force default line endings?
> 
> 
> --
> Now while composing this email I discovered String>>withUnixLineEndings.
> So I have a solution...
> testfile := 'README.md' asFileReference.
> testfile ensureCreateFile writeStreamDo: [ :stream |
> stream nextPutAll: 'aa
> bb'  withUnixLineEndings ].
> (testfile binaryReadStream contents at: 3) asCharacter   "==> Character 
> lf "
> 
> but that seems to imply that on Windows...
> 'aa
> bb' at: 3  "==> Character cr "
> 
> and on Linux (someone please confirm)...
> 'aa
> bb' at: 3   "==> Character lf "
> 
> and that is *very* curious.  Strange that I never noticed it before and 
> obviously that hasn't hurt me, 
> but considering the Principal Of Least Surprise it leaves me feeling somewhat 
> violated :)

Re: [Pharo-dev] Versioning with Iceberg

[Tim Mackinnon]

> On 30 May 2019, at 11:55, Shaping  wrote:
> 
> 7.0.3.  It loaded after a fresh clone of pharo, but with a detached head.


So are you trying to actually contribute to Pharo? You don’t normally need to 
reload pharo (if I’ve understood what you are doing). I think ben has raised a 
bug for you for that.

However, back to your other question - I had misunderstood - actually you can 
load specific project (like exercism)  via Iceberg (although a metacello script 
is often more convenient - and sometimes more precise) - if you pick Add, then 
choose GitHub, then enter the owner and project (e.g. for exercism - owner = 
exercism, project = pharo-smalltalk), this will get you the baseline (but won’t 
load any packages).

Now you have to right click on the repository, and pick the Metacello menu 
item, and then you can load baseline (which gives you the default), or you can 
enter a group name (e.g. ‘dev’ for exercism).

If you want a different version than master, then have to open the repository 
view (cmd-r), there you can select a tag to load, and then you can use the 
metecallo menu.

You can also (although somewhat painfully), right click on all the packages in 
a repository and select “load” to do them one by one.

Hope this helps.

Tim

Re: [Pharo-dev] FW: Versioning with Iceberg

[Tim Mackinnon]

Hi - I’m rather confused reading your thread as it’s not clear what you’re 
doing.

Using iceberg - I typically see the normal loading progress bars for long 
operations on the top left of the screen - often they stack below one another 
to show nested operations (aside: they are a bit ugly - but it’s a consistent 
metaphor across Pharo). I get them when loading, pulling, pushing, diffing etc. 
Do you not see them?

Back to your version question - what baseline are you loading from a repo? A 
specific example might help.

If i were to load Exercism as an example - the following page describes how to 
upgrade to a specific version of the baseline in the repo.

Eg latest vs v0.2.3

https://github.com/exercism/pharo-smalltalk/blob/master/docs/UPGRADE.md


This describes how to do it in the playground - as versions are actually loaded 
by metacello - and Iceberg builds on top of it to route things via git and make 
use of version tags etc, and it then gives the push/pull/commit operations. 
(I’m probably describing this badly - but I suspect the confusion is in here 
for you).

Having loaded your particular baseline (the code tagged as v2.0.3 for example), 
Iceberg will let you compare it to other branches - or hash versions in git.

But typically, libraries you use will give you a playground script that 
specifies a stable version - you eval that in your playground and those 
libraries will then appear in your image (and also in Iceberg).

For your project - you can formalise those dependencies by creating your own 
baseline that references those scripts as well.

But maybe you can describe better what you are doing and we can unpick what is 
happening.

Tim

Sent from my iPhone

> On 30 May 2019, at 02:07, Shaping  wrote:
> 
> Sorry, I meant progress bar, not histo….
>  
> From: Shaping [mailto:shap...@uurda.org] 
> Sent: Wednesday, May 29, 2019 20:05
> To: 'Pharo Development List' 
> Subject: RE: [Pharo-dev] Versioning with Iceberg
>  
>  
>  
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Ben 
> Coman
> Sent: Wednesday, May 29, 2019 10:58
> To: Pharo Development List 
> Subject: Re: [Pharo-dev] Versioning with Iceberg
>  
>  
>  
> On Wed, 29 May 2019 at 23:08, Shaping  wrote:
> I’m finding 7.0.3 to be more stable. 
>  
> How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by 
> default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. 
>  There are many differences.  I want to commit my image changes locally for 
> now on a 7.0.3.
>  
>  
> Its not completely clear what you want.  
>  
> You can right-click a repo > Metacello > Install baseline of.
> 
> Or right-click a repo > Repository > Remotes 
> and select one of those branches to check out.
>  
> I missed the Repository item completely, all this time.  I think I was 
> blocking it out mentally because I was already in an Iceberg window that 
> lists repos.  The doubling up is confusing and unexpected.   So we have 
> Iceberg repos wrapping Git repos?  I’m not sure I have the scheme right.
>  
> Why don’t we have the usual wait-cursors appearing on long synchronous 
> actions behind button clicks?  These lock up the system for 1 or 2 minutes 
> often.  For example, I deleted 20-odd packages the other day and waited 2 
> minutes for it to finish, wondering why the system was completely 
> unresponsive and showing no indication (no histo; no wait cursor).  This 
> happens when cloning a Git repo, too.  The histo opens about ½ second before 
> the about 1-m pull finishes.  This happened in the 7.0.3 build.  Is there a 
> policy not to use a wait-cursor if not histo is shown?
>  
> Shaping
>  

Re: [Pharo-dev] DNU Create button auto extension category

[Tim Mackinnon]

My point was that in general - method categorisation has degraded (not just 
your debugger case, but in a broader sense).

Nautilus used to infer method protocols , and if not inferred, you used to see 
protocols already in your package... now you basically have to type out 
protocols and search for them every time.

I don’t think you can even bulk categorise methods either.

I keep meaning to have a look, as it’s all quite annoying and doesn’t really 
encourage you to categorise anything as it’s too much like hard work.

Tim

Sent from my iPhone

On 12 May 2019, at 07:30, Ben Coman  wrote:

>>> On 11 May 2019, at 18:07, Ben Coman  wrote:
>>> 
>>> Currently when a DNU occurs we get this cool  button,
>>> but when this presents the dialog "New Protocol Name" I get a blank
>>> list and the default is "as yet unclassified" and I end up with a heap
>>> of such unclassified methods to sort later.
>>> 
>>> I am wondering if it could be smarter when tests are being run.  A
>>> reasonable assumption could be that the test's package name is closely
>>> related to the likely extension package name.
>>> So for a DNU, I wonder if the debugger could walk the stack to
>>> discover if a TestCase subclass was on the stack (e.g. MyTestCase) and
>>> then determine which package MyTestCase belonged to, and present that
>>> as a choice for "New Protocol Name", helping categorize extension
>>> methods.
>>> 
>>> I've started to play like this...
>>> 
>>> TestCase subclass: #MyTestRoot
>>> 
>>> MyTestRoot >> runCase
>>>   [ super runCase ]
>>>   on: MessageNotUnderstood
>>>   do: [ :ex |
>>> "do something here, but for now..."
>>>  ex pass
>>>  ].
>>> 
>>> but before getting to deep, I'm seeking suggestions/solutions from the
>>> community.
> 
>> On Sun, 12 May 2019 at 05:06, Tim Mackinnon  wrote:
>> 
>> It’s a good point Ben - in fact categorisation in general has not been 
>> finished in pharo7 -
>> the move to Calypso lost smart method categories and its on the todo list to 
>> fix and improve it.
> 
> I don't think this is related to Calypso, more to do with the debugger.
> I got what I wanted with the following change...
> ```
> DoesNotUnderstandDebugAction>>defaultProtocol   "new method"
>"Facilitate  DNU with TDD creating extension methods by
> suggesting that as default protocol"
>| interruptedContext candidateContext |
>"self halt"
>interruptedContext := self interruptedContext.
>candidateContext := interruptedContext sender.
>[ candidateContext isNil or: [ candidateContext contextClass
> isKindOf: TestCase class ] ]
>whileFalse: [ candidateContext := candidateContext sender ].
>candidateContext ifNotNil: [
>| testPackage dnuPackage|
>dnuPackage := interruptedContext receiver class package.
>testPackage := candidateContext contextClass package.
>(testPackage = dnuPackage) ifFalse: [ ^ '*', testPackage name 
> ].
>].
>^'as yet unclassified'
> 
> DoesNotUnderstandDebugAction>>executeAction  "diff modified method"
>| msg msgCategory chosenClass exception |
>msg := self interruptedContext tempAt: 1.
>exception := self interruptedContext tempAt: 2.
>(exception class == ClassNotUnderstood) ifTrue: [
>self createMissingClassWith: exception variableNode
> in: self interruptedContext ].
>chosenClass := self
>askForSuperclassOf: self interruptedContext receiver class
>toImplement: msg selector
>ifCancel: [^self].
> -msgCategory := (self askForCategoryIn: chosenClass default:
> 'as yet unclassified' ).
> +msgCategory := (self askForCategoryIn: chosenClass default:
> self defaultProtocol).
>  self  session
>implement: msg
>classified: msgCategory
>inClass: chosenClass
>forContext: self interruptedContext.
>self debugger selectTopContext
> ```
> 
> Tim, Can you trial this with your Exercism Die exercise?
> 
> Alternatively an isolated test...
> ```
> Object subclass: MyApp ... package: 'MyPackage'
> 
> TestCase subclass: MyTestCase ... package: 'MyPackage'
> 
> MyTestCase >> testAutoExtensionProtocol
>MyApp new unknown
> ```
> 
> Run the test then click  button to add following method with
> default protocol... as yet unclassified
> ```
> MyApp >> unknown
>  42 unknown
> ```
> 
> Click  button to add method with default protocol...  *MyPackage
> 
> cheers -ben
> 
> P.S. Next question is how to create a unit test for such behaviour ??
> 

Re: [Pharo-dev] DNU Create button auto extension category

[Tim Mackinnon]

It’s a good point Ben - in fact categorisation in general has not been finished 
in pharo7 - the move to Calypso lost smart method categories and its on the 
todo list to fix and improve it.

Tim

Sent from my iPhone

> On 11 May 2019, at 18:07, Ben Coman  wrote:
> 
> Currently when a DNU occurs we get this cool  button,
> but when this presents the dialog "New Protocol Name" I get a blank
> list and the default is "as yet unclassified" and I end up with a heap
> of such unclassified methods to sort later.
> 
> I am wondering if it could be smarter when tests are being run.  A
> reasonable assumption could be that the test's package name is closely
> related to the likely extension package name.
> So for a DNU, I wonder if the debugger could walk the stack to
> discover if a TestCase subclass was on the stack (e.g. MyTestCase) and
> then determine which package MyTestCase belonged to, and present that
> as a choice for "New Protocol Name", helping categorize extension
> methods.
> 
> I've started to play like this...
> 
> TestCase subclass: #MyTestRoot
> 
> MyTestRoot >> runCase
>[ super runCase ]
>on: MessageNotUnderstood
>do: [ :ex |
>  "do something here, but for now..."
>   ex pass
>   ].
> 
> but before getting to deep, I'm seeking suggestions/solutions from the
> community.
> 
> cheers -ben
> 

Re: [Pharo-dev] IceCredentialsProvider sshCredentials ?

[Tim Mackinnon]

Not sure if this helps - but that error is rather arbitrary.

I  got the same when I deleted the local iceberg directory vs my project 
directory in iceberg. Could this be a possibility? It doesn’t react well to 
missing directories?

Tim

Sent from my iPhone

> ?On 7 May 2019, at 15:33, Sven Van Caekenberghe  wrote:
> 
> I am trying to deploy on a server by building a Pharo image there.
> 
> I want to use a readonly 'deploy user', using a specific certificate.
> 
> I have been trying lots of things, but I cannot get where I want.
> 
> So the user account is arbitrary, it just contains a key pair. If I add the 
> key pair to the ssh-agent, I can clone my repository on the command line.
> 
> Now I want to script this from Pharo. The script starts as follows:
> 
> | remote location |
> remote := IceGitRemote url: 
> 'ssh://g...@bitbucket.myhost.be:1234/tthree/t3-pharo.git'.
> location := FileLocator localDirectory / 'iceberg' / remote projectName.
> 
> IceRepositoryCreator new 
> remote: remote;
> location: location;
> createRepository.
> 
> On my development machine (macOS), this works fine.
> But this does not work on the Linux server, it says
> 
> IceAuthenticationError: There was an authentication error while trying to 
> execute the operation: . 
> This happens usually because you didn't provide a valid set of credentials. 
> You may fix this problem in different ways: 
> 
> 1. adding your keys to ssh-agent, executing ssh-add ~/.ssh/id_rsa in your 
> command line.
> 2. adding your keys in settings (open settings browser search for "Use custom 
> SSH keys" and
> add your public and private keys).
> 3. using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git)
> 
> It does not matter if the ssh-agent has the certificate listed (ssh-add).
> 
> Adding 
> 
> IceCredentialsProvider useCustomSsh: true.
> IceCredentialsProvider sshCredentials
>   publicKey: '/home/t3/.ssh/id_deploy_pharo_ed25519.pub';
>   privateKey: '/home/t3/.ssh/id_deploy_pharo_ed25519'
> 
> Does not make a difference. Is this supposed to work ?
> 
> Maybe there is some other problem ?
> 
> Sven
> 
> 

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

[Tim Mackinnon]

> On 17 Apr 2019, at 23:43, Denis Kudriashov  wrote:
> 
> Somebody should just decide that new version needs to be to back ported. 

Who is the somebody that would decide? If we have to live with Pharo 7.x for 
the next year (possibly a bit less) - some of the UI fixes would be much 
appreciated, particularly if its easy to do.

Perhaps if we do a 7.0.4 we might do that?

Tim

p.s. 7.0.3 definitely doesn’t fix the font glitch (sadly), and Guille’s fix 
cause my image to deadlock for 3-5 minutes when I see it (which might actually 
be helpful - is it could conform a specific type of problem)

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

[Tim Mackinnon]

FYI - I was able to confirm that my working 703 image continues to show the 
issue (Exercism+Mirage seem to cause it - but I suspect it’s Mirage rendering 
thumbnails in multiple threads that stresses things).

Guille has come up with a filein that has some more aggressive mutex code (from 
my quick glance), so I am running with that to see if I can empirically show it 
helps.

Tim

Sent from my iPhone

> On 16 Apr 2019, at 08:30, ducasse  wrote:
> 
> Hi tim
> 
> I think that this is better to create a new issue.
> 
> Stef
> 
> 
>> On 15 Apr 2019, at 09:57, Tim Mackinnon  wrote:
>> 
>> No problem - it’s a bit early to tell if it’s the same as before  - my sense 
>> is that it’s slightly improved. I had that 7.0.3 image in light use for 3-4 
>> hours before I noticed it. In 7.0.2 it would happen within 5-20 mins.
>> 
>> I deliberately loaded Mirage as I recalled it was the catalyst before, and I 
>> think this might still be the case - but I’ll continue to use this setup to 
>> give more details.
>> 
>> Do we re-open the previous issue and our feedback there?
>> 
>> Tim
>> 
>> Sent from my iPhone
>> 
>>> On 15 Apr 2019, at 08:14, "teso...@gmail.com"  wrote:
>>> 
>>> I am afraid we will need to give more love to it.
>>> We need a proper solution, hacking it is not working. We will have to 
>>> refactor implementation and modify the users.
>>> It is not that we are lazy (that we are) but also it is ugly and full of 
>>> magic numbers. 
>>> 
>>> But we will win, we must win! 
>>> 
>>> Thanks again for the report!
>>> 
>>>> On Mon, Apr 15, 2019 at 9:10 AM teso...@gmail.com  
>>>> wrote:
>>>> Thanks a lot, founding the issue is important.
>>>> For sure I missed some other users of freetype doing the same!!
>>>> 
>>>>> On Mon, Apr 15, 2019 at 1:14 AM Tim Mackinnon  wrote:
>>>>> I hate to be the bearer of bad news - but 7.0.3 on OSX still has the font 
>>>>> glyph issue (see how my menus have started to go) - saving my image has 
>>>>> fixed it (for now). I do have Mirage loaded in my image ( the latest 
>>>>> version, and I was showing you guys how that seems to stress it a bit 
>>>>> more).
>>>>> 
>>>>> Tim
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 14 Apr 2019, at 15:16, teso...@gmail.com wrote:
>>>>>> 
>>>>>> Like in the Oscars, I was thanking everybody. ;) 
>>>>>> 
>>>>>> On Fri, 12 Apr 2019, 21:40 Stéphane Ducasse >>>>> wrote:
>>>>>>> what is the academy?
>>>>>>> :)
>>>>>>> 
>>>>>>> stef
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 12 Apr 2019, at 17:26, teso...@gmail.com wrote:
>>>>>>>> 
>>>>>>>> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying 
>>>>>>>> font corruption font.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Changes Log
>>>>>>>> 
>>>>>>>> #2781 Fix comment on OSWindow >> startTextInput
>>>>>>>> #3160 2975-Problem-when-you-read-an-mcz-pharo7
>>>>>>>> #3130 Improving the performance of SourceFileArray
>>>>>>>> #3164 MailMessage can not send mails with attachment in Pharo7
>>>>>>>> #3149 
>>>>>>>> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat
>>>>>>>> #3178 Fix for corrupted fonts in Pharo7
>>>>>>>> Detailed Diff: v7.0.2...pharo-project:v7.0.3
>>>>>>>> https://github.com/pharo-project/pharo/releases/tag/v7.0.3
>>>>>>>> 
>>>>>>>> All the images are available in ZeroConf and in the Pharo Launcher.
>>>>>>>> 
>>>>>>>> Thanks to all the collaborators especially: 
>>>>>>>> 
>>>>>>>> - David 
>>>>>>>> - Guille
>>>>>>>> - Pavel
>>>>>>>> - Christophe
>>>>>>>> - Theo
>>>>>>>> - Sabine
>>>>>>>> - Sven
>>>>>>>> 
>>>>>>>> And to all the people that helped to make this release in a couple of 
>>>>>>>> minutes. 
>>>>>>>> And thanks to the academy! 
>>>>>>>> 
>>>>>>>> Pablo
>>>>>>> 
>>>>>>> 
>>>>>>> Stéphane Ducasse
>>>>>>> http://stephane.ducasse.free.fr
>>>>>>> http://www.synectique.eu / http://www.pharo.org 
>>>>>>> 03 59 35 87 52
>>>>>>> Assistant: Julie Jonas 
>>>>>>> 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
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Pablo Tesone.
>>>> teso...@gmail.com
>>> 
>>> 
>>> -- 
>>> Pablo Tesone.
>>> teso...@gmail.com
> 

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

[Tim Mackinnon]

No problem - it’s a bit early to tell if it’s the same as before  - my sense is 
that it’s slightly improved. I had that 7.0.3 image in light use for 3-4 hours 
before I noticed it. In 7.0.2 it would happen within 5-20 mins.

I deliberately loaded Mirage as I recalled it was the catalyst before, and I 
think this might still be the case - but I’ll continue to use this setup to 
give more details.

Do we re-open the previous issue and our feedback there?

Tim

Sent from my iPhone

> On 15 Apr 2019, at 08:14, "teso...@gmail.com"  wrote:
> 
> I am afraid we will need to give more love to it.
> We need a proper solution, hacking it is not working. We will have to 
> refactor implementation and modify the users.
> It is not that we are lazy (that we are) but also it is ugly and full of 
> magic numbers. 
> 
> But we will win, we must win! 
> 
> Thanks again for the report!
> 
>> On Mon, Apr 15, 2019 at 9:10 AM teso...@gmail.com  wrote:
>> Thanks a lot, founding the issue is important.
>> For sure I missed some other users of freetype doing the same!!
>> 
>>> On Mon, Apr 15, 2019 at 1:14 AM Tim Mackinnon  wrote:
>>> I hate to be the bearer of bad news - but 7.0.3 on OSX still has the font 
>>> glyph issue (see how my menus have started to go) - saving my image has 
>>> fixed it (for now). I do have Mirage loaded in my image ( the latest 
>>> version, and I was showing you guys how that seems to stress it a bit more).
>>> 
>>> Tim
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 14 Apr 2019, at 15:16, teso...@gmail.com wrote:
>>>> 
>>>> Like in the Oscars, I was thanking everybody. ;) 
>>>> 
>>>> On Fri, 12 Apr 2019, 21:40 Stéphane Ducasse >>> wrote:
>>>>> what is the academy?
>>>>> :)
>>>>> 
>>>>> stef
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 12 Apr 2019, at 17:26, teso...@gmail.com wrote:
>>>>>> 
>>>>>> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying 
>>>>>> font corruption font.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Changes Log
>>>>>> 
>>>>>> #2781 Fix comment on OSWindow >> startTextInput
>>>>>> #3160 2975-Problem-when-you-read-an-mcz-pharo7
>>>>>> #3130 Improving the performance of SourceFileArray
>>>>>> #3164 MailMessage can not send mails with attachment in Pharo7
>>>>>> #3149 
>>>>>> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat
>>>>>> #3178 Fix for corrupted fonts in Pharo7
>>>>>> Detailed Diff: v7.0.2...pharo-project:v7.0.3
>>>>>> https://github.com/pharo-project/pharo/releases/tag/v7.0.3
>>>>>> 
>>>>>> All the images are available in ZeroConf and in the Pharo Launcher.
>>>>>> 
>>>>>> Thanks to all the collaborators especially: 
>>>>>> 
>>>>>> - David 
>>>>>> - Guille
>>>>>> - Pavel
>>>>>> - Christophe
>>>>>> - Theo
>>>>>> - Sabine
>>>>>> - Sven
>>>>>> 
>>>>>> And to all the people that helped to make this release in a couple of 
>>>>>> minutes. 
>>>>>> And thanks to the academy! 
>>>>>> 
>>>>>> Pablo
>>>>> 
>>>>> 
>>>>> Stéphane Ducasse
>>>>> http://stephane.ducasse.free.fr
>>>>> http://www.synectique.eu / http://www.pharo.org 
>>>>> 03 59 35 87 52
>>>>> Assistant: Julie Jonas 
>>>>> 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
>>>>> 
>>> 
>> 
>> 
>> -- 
>> Pablo Tesone.
>> teso...@gmail.com
> 
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com

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

[Tim Mackinnon]

I hate to be the bearer of bad news - but 7.0.3 on OSX still has the font glyph 
issue (see how my menus have started to go) - saving my image has fixed it (for 
now). I do have Mirage loaded in my image ( the latest version, and I was 
showing you guys how that seems to stress it a bit more).

Tim






> On 14 Apr 2019, at 15:16, teso...@gmail.com wrote:
> 
> Like in the Oscars, I was thanking everybody. ;) 
> 
> On Fri, 12 Apr 2019, 21:40 Stéphane Ducasse   wrote:
> what is the academy?
> :)
> 
> stef
> 
> 
> 
>> On 12 Apr 2019, at 17:26, teso...@gmail.com  wrote:
>> 
>> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font 
>> corruption font.
>> 
>> 
>> 
>> Changes Log
>> 
>> #2781  Fix comment on 
>> OSWindow >> startTextInput
>> #3160  
>> 2975-Problem-when-you-read-an-mcz-pharo7
>> #3130  Improving the 
>> performance of SourceFileArray
>> #3164  MailMessage can not 
>> send mails with attachment in Pharo7
>> #3149  
>> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat
>> #3178  Fix for corrupted 
>> fonts in Pharo7
>> Detailed Diff: v7.0.2...pharo-project:v7.0.3 
>> 
>> https://github.com/pharo-project/pharo/releases/tag/v7.0.3 
>> 
>> All the images are available in ZeroConf and in the Pharo Launcher.
>> 
>> Thanks to all the collaborators especially: 
>> 
>> - David 
>> - Guille
>> - Pavel
>> - Christophe
>> - Theo
>> - Sabine
>> - Sven
>> 
>> And to all the people that helped to make this release in a couple of 
>> minutes. 
>> And thanks to the academy! 
>> 
>> Pablo
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr 
> http://www.synectique.eu  / http://www.pharo.org 
>  
> 03 59 35 87 52
> Assistant: Julie Jonas 
> 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] [ANN] Pharo 7.0.3

[Tim Mackinnon]

This is great - I’m pleased we can get fixes like this (and keen to get passed 
that font issue which was driving me crazy).

A small related question - how do ensure we get fixes from sub projects 
considered too? I’d really like to see: 
https://github.com/pharo-ide/Calypso/pull/451 as it’s annoying not being able 
to move methods between classes. There are a few other Calypso gems in there 
too (and quite a few more to fix).

I worry that having all these sub-projects makes it a bit complicated to get 
them included?

Tim

Sent from my iPhone

> On 12 Apr 2019, at 16:26, "teso...@gmail.com"  wrote:
> 
> Pharo 7.0.3 contains several bugfixes, notably a fix for the annoying font 
> corruption font.
> 
> 
> 
> Changes Log
> 
> #2781 Fix comment on OSWindow >> startTextInput
> #3160 2975-Problem-when-you-read-an-mcz-pharo7
> #3130 Improving the performance of SourceFileArray
> #3164 MailMessage can not send mails with attachment in Pharo7
> #3149 
> 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat
> #3178 Fix for corrupted fonts in Pharo7
> Detailed Diff: v7.0.2...pharo-project:v7.0.3
> https://github.com/pharo-project/pharo/releases/tag/v7.0.3
> 
> All the images are available in ZeroConf and in the Pharo Launcher.
> 
> Thanks to all the collaborators especially: 
> 
> - David 
> - Guille
> - Pavel
> - Christophe
> - Theo
> - Sabine
> - Sven
> 
> And to all the people that helped to make this release in a couple of 
> minutes. 
> And thanks to the academy! 
> 
> Pablo

Re: [Pharo-dev] how implement isAbstract?

[Tim Mackinnon]

 Calypso warns you about missing methods if it doesn’t understand a class is 
abstract, so it’s useful to avoid those warnings otherwise you become 
desensitised to them.

Tim

Sent from my iPhone

> On 31 Mar 2019, at 22:06, ducasse  wrote:
> 
> Frankly I found strange that we care about this because 
>   we can still instantiate an abstract class
>   and I do not really see how annotating that a class is abstract help 
> us. 
>   If I can instantiate an object and send messages and the class is 
> abstract but there is no
>   usage of abstract messages who cares?
> May be I do not have such scenarios. 
> 
> Stef
> 
>> On 31 Mar 2019, at 22:30, Norbert Hartl  wrote:
>> 
>> 
>> 
>>> Am 30.03.2019 um 21:05 schrieb Denis Kudriashov :
>>> 
>>> We can also look into it from the other side. All these methods are 
>>> definitely a kind of code duplication. 
>>> I think what we need here is an explicit property for classes. It could be 
>>> even part of class definition.
>> 
>> I use it myself but it always feels a bit strange. On the one hand a class 
>> is abstract if it includes something like subclassResponsibility and on the 
>> other hand we try to make it some kind of type. If it would be the latter 
>> one you could make that a Trait. Feels even more strange but 
>> 
>> Norbert
>>> BTW do we plan new class definition in Pharo 8? 
>>> 
>>> сб, 30 мар. 2019 г. в 18:35, Denis Kudriashov :
 Hello.
 
 We did recently several cleanups by marking abstract classes as abstract 
 using #isAbstract method 
 (https://github.com/pharo-project/pharo/pull/3087, 
 https://github.com/pharo-ide/Calypso/pull/462) .
 
 I would like to discuss here and decide what the right way to implement 
 this method.  
 
 The logic behind is to only return true when receiver is defining class of 
 this method. And it should be false for any subclasses (if they do not 
 implement own #isAbstract method).
 
 There is old pattern for implementation to compare name of class:
 
 MyAbstractClass class>>isAbstract
   ^self name == #MyAbstractClass 
 
 It is used in many places (mostly tests). And it was used in recent Pharo 
 PR (3087).
 
 We have another pattern in other places which simply compare self with 
 class:
 
 MyAbstractClass class>>isAbstract
   ^self == MyAbstractClass 
 
 And in Calypso I used "more simplified" version using equality:
 
 MyAbstractClass class>>isAbstract
   ^self = MyAbstractClass 
 
 I think we would all agree that simplest version is last one. It does not 
 raise any question about why we compare name or why we use identity 
 comparison. So this is my choice in this discussion.
 
 Please write arguments about your preferred implementation. And let's 
 choose single way at the end. There is an idea to add a command into 
 browser to make classes abstract. And this decision will be used as a 
 template.
 
 Best regards,
 Denis
 
> 

Re: [Pharo-dev] how implement isAbstract?

[Tim Mackinnon]

I also find that the last one resonates with what I would expect - and a real 
class autocompletes easily too.

I also wonder if a class with subclasses should be considered abstract unless 
specifically marked otherwise (but we need a simple way of doing this if we can 
think of one - which isn’t overly clever)

Tim

Sent from my iPhone

> On 30 Mar 2019, at 19:21, Cyril Ferlicot D.  wrote:
> 
>> Le 30/03/2019 à 19:35, Denis Kudriashov a écrit :
>> Hello.
>> 
>> We did recently several cleanups by marking abstract classes as abstract
>> using #isAbstract method
>> (https://github.com/pharo-project/pharo/pull/3087, 
>> https://github.com/pharo-ide/Calypso/pull/462)
>> .
>> 
>> I would like to discuss here and decide what the right way to implement
>> this method.  
>> 
>> The logic behind is to only return true when receiver is defining class
>> of this method. And it should be false for any subclasses (if they do
>> not implement own #isAbstract method).
>> 
>> There is old pattern for implementation to compare name of class:
>> 
>>MyAbstractClass class>>isAbstract
>>  ^self name == #MyAbstractClass 
>> 
>> 
>> It is used in many places (mostly tests). And it was used in recent
>> Pharo PR (3087).
>> 
>> We have another pattern in other places which simply compare self with
>> class:
>> 
>>MyAbstractClass class>>isAbstract
>>  ^self == MyAbstractClass 
>> 
>> 
>> And in Calypso I used "more simplified" version using equality:
>> 
>>MyAbstractClass class>>isAbstract
>>  ^self = MyAbstractClass 
>> 
>> I think we would all agree that simplest version is last one. It does
>> not raise any question about why we compare name or why we use identity
>> comparison. So this is my choice in this discussion.
>> 
>> Please write arguments about your preferred implementation. And let's
>> choose single way at the end. There is an idea to add a command into
>> browser to make classes abstract. And this decision will be used as a
>> template.
>> 
>> 
> 
> Hi,
> 
> Personally I always used the last one. (self = MyAbstractClass)
> 
> At first it is because it's the first implementation I saw. Then later,
> after seen the other two, I sticked with this one because it seems to be
> the simpler for me and I like my code to stay the simpler possible if
> there is no problem with that.
> 
> Until now I never got a problem with this implementation.
> 
>> Best regards,
>> Denis
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

Re: [Pharo-dev] Variables in auto-completion

[Tim Mackinnon]

Yes - I noticed that too and raised a similar issue: 
https://github.com/pharo-project/pharo/issues/2855 


> On 28 Mar 2019, at 10:48, Julien  wrote:
> 
> 
> 
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille
> http://juliendelplanque.be/phd.html 
> Equipe Rmod, Inria
> Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
> Numéro de téléphone: +333 59 35 86 40
> 
>> Le 28 mars 2019 à 11:15, Cyril Ferlicot > > a écrit :
>> 
>> Hi,
>> 
>> I remember that in old Pharo versions, the auto-completion added the
>> variables at the top of the completion list. Now they are at the
>> bottom under the classes.
>> 
>> The original version worked better for me.
> 
> I preferred previous version as well.
> 
> Cheers,
> 
> Julien
> 
>> The current version really
>> annoys me since most of the time I would prefer to have a variables
>> completed. Is there a setting somewhere to get the old behavior back?
>> If not, does someone knowing the implementation of the auto-completion
>> knows where I could put a metalink to get the old behavior back for
>> me?
>> 
>> -- 
>> Cyril Ferlicot
>> https://ferlicot.fr 
>> 
> 

Re: [Pharo-dev] PR2789, Rubric integration revert

[Tim Mackinnon]

Guys - from the sidelines, I’m feeling for all sides here. But this is an 
important point that it’s useful to debate openly and without hard feeling. (So 
thanks to all of you for this passion).

Please lets ensure we don’t get to a place that stops the will to contribute, 
nor the drive for improvement. Both are very important. And I’ve appreciated 
both!

It sounds like a pattern is emerging where in the early days after a new 
release there is the drive to break a bit more to try and make a huge leap 
forward... I think we can all understand that, but it’s useful to be reminded 
about it and put some exit criterion put in place (as in the trenches their is 
also the same excitement to nail some of the niggly bits too).

In the same vein, however, can we understand if these changes have broken P8 
badly (is it just a a certain area?). I also think it is worth understanding 
the pro’s and con’s of doing things in a branch. I think we would all agree 
that not breaking P8 mainline is optimal,  but equally we’ve all experienced 
merge hell too (and iceberg is still a nascent solution that is grappling with 
this problem). 

So was it just too hard to branch? And if it was, should we put a little - this 
is the process for hard things like this, safety check in place? Equally, if 
it’s “oops”, I think we all can understand that too.

But most of all - we need everyone on board to make needed improvements, and 
keep our environment and community healthy!

Tim

Sent from my iPhone

> On 26 Mar 2019, at 17:50, ducasse  wrote:
> 
> I think that you are exaggerating. 
> We are not working on Pharo 100% of our time and life is complex. 
> 
> Stef
> 
>> ducasse  wrote:
>>> Hi stephan
>>> 
 Unless someone is working on fixing it today, I want this PR reverted.
 Issues 2865, 2963, 2964, 2980, 3013
 
 Stephan
>>> 
>>> Nobody is working on Pharo this is well known.
>> 
>> I am feeling angry and ignored. I am trying to contribute and am frustrated
>> in doing so. I am asked to go through fogbugz and make sure that important
>> issues are reopened on github. I do so and get comments that bugs don’t
>> solve themselves, on the one where I notice that Rubric is not ready. I
>> find and fix important other bugs and try to integrate them and notice that
>> a lot of things don’t work as they should. CI has been systematically red.
>> The first thing I notice is that an in-image test is red, with a trivial to
>> fix issue. Then I run into all kinds of other problems with Rubric not
>> implementing something. And I’m not the only one, looking at the issue
>> tracker. So I look back trough github and see no signs of improvements in
>> the past 14 days. I collected the relevant issues and reached out on github
>> and discord first, without getting a useful reaction. This is not the
>> development process we are using, as I understand it. 
>> 
>> Please revert the PR. I have been working on FFI, Taskbar and CI bugs and I
>> want to be able to commit, integrate PRs and make Pharo better. Pharo is
>> mine.  
>> 
>>> 
>>> Sorry but I did not like the ton of your email, especially because there 
>>> are 
>>> lot of information that you do not know. 
>> 
>> I’m up to date with the github commits, issues and PRs, Discord and the
>> mailing lists. If you feel contributors need more information, please make
>> sure we get it
> 
> There are information about private people and this is private!
> 
>>> Now if you want to help, add the issue to the projects so that I can work
>>> on them with Alain
>>> and others. Else I will do it. 
>> 
>> Projects don’t work yet. 
> 
> I just added your issues to them.
> 
>> If you want time to focus on Rubric only and don’t want other contributions
>> to Pharo 8 at the moment, then please announce so. Or use a branch. Don’t
>> integrate a PR that breaks CI and then don’t fix the issues for two weeks. 
> 
> Come on. Stop that kind of bullshit.
> We have been integrating fixes since the beginning with tests not passing. 
> But you convince me I decided that I will stop reviewing issues and take 
> responsibility 
> to integrate fixes. Esteban and marcus will do it. 
> 
> I will focus on my projects because I’m total disagreement. 
> My point of view is that life is complex but you have the right to have rigid 
> views and I have the right
> to drop and use my time for something else. 
> 
> Stef
> 
> 
> 

Re: [Pharo-dev] How to manage your code with Iceberg

[Tim Mackinnon]

Damn you autocorrect - I mean “BOF” about releaser.

> On 24 Mar 2019, at 20:31, Tim Mackinnon  wrote:
> 
> Possibly it could be a bot - as I’d be interested in understanding more about 
> that too.
> 
>> On 24 Mar 2019, at 17:51, Tudor Girba  wrote:
>> 
>> We’d be happy to talk about it :)
>> 
>> Doru
>> 
>> 
>> 
>>> On Mar 24, 2019, at 4:40 PM, ducasse  wrote:
>>> 
>>> We will add patterns of management. 
>>> 
>>> I would like to discuss about releaser at Pharodays :)
>>> 
>>> Stef
>>> 
>>>> On 24 Mar 2019, at 15:21, Tudor Girba  wrote:
>>>> 
>>>> Nice work! And very useful for newcomers, too :)
>>>> 
>>>> Doru
>>>> 
>>>>> On Mar 24, 2019, at 10:22 AM, Stéphane Ducasse 
>>>>>  wrote:
>>>>> 
>>>>> Hi 
>>>>> 
>>>>> I'm happy to announce a new booklet (soon to be released) on how to 
>>>>> manage code with Iceberg. We plan to discuss management patterns in the 
>>>>> future.
>>>>> 
>>>>> https://github.com/SquareBracketAssociates/Booklet-ManagingCode
>>>>> 
>>>>> Stef and Guille
>>>>> 
>>>>> 
>>>>> Stéphane Ducasse
>>>>> http://stephane.ducasse.free.fr
>>>>> http://www.synectique.eu / http://www.pharo.org 
>>>>> 03 59 35 87 52
>>>>> Assistant: Julie Jonas 
>>>>> 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
>>>>> 
>>>> 
>>>> --
>>>> www.feenk.com
>>>> 
>>>> "Presenting is storytelling."
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> www.feenk.com
>> 
>> "Sometimes the best solution is not the best solution."
>> 
>> 
> 
> 

Re: [Pharo-dev] How to manage your code with Iceberg

[Tim Mackinnon]

Possibly it could be a bot - as I’d be interested in understanding more about 
that too.

> On 24 Mar 2019, at 17:51, Tudor Girba  wrote:
> 
> We’d be happy to talk about it :)
> 
> Doru
> 
> 
> 
>> On Mar 24, 2019, at 4:40 PM, ducasse  wrote:
>> 
>> We will add patterns of management. 
>> 
>> I would like to discuss about releaser at Pharodays :)
>> 
>> Stef
>> 
>>> On 24 Mar 2019, at 15:21, Tudor Girba  wrote:
>>> 
>>> Nice work! And very useful for newcomers, too :)
>>> 
>>> Doru
>>> 
 On Mar 24, 2019, at 10:22 AM, Stéphane Ducasse  
 wrote:
 
 Hi 
 
 I'm happy to announce a new booklet (soon to be released) on how to manage 
 code with Iceberg. We plan to discuss management patterns in the future.
 
 https://github.com/SquareBracketAssociates/Booklet-ManagingCode
 
 Stef and Guille
 
 
 Stéphane Ducasse
 http://stephane.ducasse.free.fr
 http://www.synectique.eu / http://www.pharo.org 
 03 59 35 87 52
 Assistant: Julie Jonas 
 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
 
>>> 
>>> --
>>> www.feenk.com
>>> 
>>> "Presenting is storytelling."
>>> 
>>> 
>> 
>> 
>> 
> 
> --
> www.feenk.com
> 
> "Sometimes the best solution is not the best solution."
> 
> 

Re: [Pharo-dev] Missing tests for FFI in CI

[Tim Mackinnon]

That is awesome - great work chasing all of that!

Any idea of what kinds of things would have been impacted that we can all keep 
an eye out for or retest?

Also, Is there anything useful we can add to our process to try and avoid this 
in the future?

Tim

Sent from my iPhone

> On 21 Mar 2019, at 07:00, Stephan Eggermont  wrote:
> 
> Yesterday, we tracked down a serious issue in 64 bit FFI. After giving up
> with our own code, we made a fresh start with the latest base image and
> OSWindows. We were finally able to figure out what went wrong with two
> simple tests that were failing in 64 bit that worked correctly in 32 bit. 
> 
> FFIConstantHandleType externalType is the wrong size
> 
> After confirming that and making it work, we were told that a number of FFI
> fixes were done by Nicolas and Eliot in Squeak that did not get integrated
> in Pharo. Applying the changes from the latest Squeak FFI resolved the
> problem, and a few that we were unaware of. 
> 
> Stephan
> 
> 
> 
> 

Re: [Pharo-dev] Why everybody could have an impact?

[Tim Mackinnon]

Yes, I got to do it (so he could help in a small way) - 
https://github.com/pharo-project/pharo/issues/2939

And I annotated it.

Tim

Sent from my iPhone

> On 20 Mar 2019, at 20:08, ducasse  wrote:
> 
> Hi tim
> 
> Can you report it precisely because right now it is not actionable. 
> And yes doing something is a challenge. Doing nothing is much more 
> confortable because nothing breaks, and you die relaxed. 
> 
> Stef
> 
>> On 20 Mar 2019, at 20:17, Tim Mackinnon  wrote:
>> 
>> Ironically - one of my Exercism testers hit an issue with extract method 
>> about when you typed this... it’s seems there has a difference between 
>> “Suggestions | Extract method”  and “Source Code | Extract method” sigh... 
>> the former gives a walk back ... and it’s due to a strange misspelled 
>> variable “previousSelectionHighligth” not being initialised.
>> 
>> So yeah - this all needs testing and fixing.
>> 
>> Tim
>> 
>> Sent from my iPhone
>> 
>>> On 20 Mar 2019, at 17:16, ducasse  wrote:
>>> 
>>> Hi
>>> 
>>> to relax I was going over RB code because we will start to improve the 
>>> refactoring. 
>>> And I started to add tests (yes the dummy little things that everybody can 
>>> write but 
>>> that most people prefer to think they do and talk about). 
>>> And writing such super super stupid tests
>>> 
>>> testCheckInvalidMethodName
>>>  "Usually used to validate input."
>>> 
>>>  self deny: (RBCondition checkMethodName: 'fofo fo').
>>>  self deny: (RBCondition checkMethodName: '123fofo').
>>>  "self deny: (RBCondition checkMethodName: 'foo::')."
>>>  "self deny: (RBCondition checkMethodName: 'agr:goo:aa').”
>>> 
>>> 
>>> checkMethodName: aString
>>>  "Return whether the argument aName is can represent a selector"
>>> 
>>>  ^ aString isString and: [ RBScanner isSelector: aString ]
>>> 
>>> 
>>> I found that RBScanner reports that 
>>> 
>>> #foo:: or 'agr:goo:aa’ is a valid selector :(
>>> 
>>> So if you **really** want to help pharo this is not that difficult. 
>>> 
>>> Now this is a matter of will. 
>>> 
>>> Stef
>>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] Why everybody could have an impact?

[Tim Mackinnon]

Ironically - one of my Exercism testers hit an issue with extract method about 
when you typed this... it’s seems there has a difference between “Suggestions | 
Extract method”  and “Source Code | Extract method” sigh... the former gives a 
walk back ... and it’s due to a strange misspelled variable 
“previousSelectionHighligth” not being initialised.

So yeah - this all needs testing and fixing.

Tim

Sent from my iPhone

> On 20 Mar 2019, at 17:16, ducasse  wrote:
> 
> Hi
> 
> to relax I was going over RB code because we will start to improve the 
> refactoring. 
> And I started to add tests (yes the dummy little things that everybody can 
> write but 
> that most people prefer to think they do and talk about). 
> And writing such super super stupid tests
> 
> testCheckInvalidMethodName
>"Usually used to validate input."
> 
>self deny: (RBCondition checkMethodName: 'fofo fo').
>self deny: (RBCondition checkMethodName: '123fofo').
>"self deny: (RBCondition checkMethodName: 'foo::')."
>"self deny: (RBCondition checkMethodName: 'agr:goo:aa').”
> 
> 
> checkMethodName: aString
>"Return whether the argument aName is can represent a selector"
>
>^ aString isString and: [ RBScanner isSelector: aString ]
> 
> 
> I found that RBScanner reports that 
> 
> #foo:: or 'agr:goo:aa’ is a valid selector :(
> 
> So if you **really** want to help pharo this is not that difficult. 
> 
> Now this is a matter of will. 
> 
> Stef
> 

Re: [Pharo-dev] [Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

[Tim Mackinnon]

Yes point taken, should have mentioned - I will review all mine and close 
obsolete ones first.

Sent from my iPhone

> On 19 Mar 2019, at 11:20, Esteban Lorenzano  wrote:
> 
> I do not like that tool :)
> 
> PLEASE do not blindly move issues from FogBugz to GitHub, if that would have 
> been our purpose we would have done it!
> 
> Migrate the issues that are relevant for you. And for relevant I mean: Just 
> the ones that you actually find in P7-8. 
> 
> Thing is… many of those issues are no longer relevant (because of many 
> things).
> 
> Esteban
> 
>> On 19 Mar 2019, at 12:12, Tim Mackinnon  wrote:
>> 
>> Yes - Cyril is a tool meister…. ;)
>> 
>>> On 19 Mar 2019, at 10:08, Marcus Denker  wrote:
>>> 
>>> Hi,
>>> 
>>> I think Cyril has some kind of tool? Yes, that might be interesting...
>>> 
>>>> On 18 Mar 2019, at 19:26, Tim Mackinnon  wrote:
>>>> 
>>>> Marcus - do we just manually copy over the title and description (and any 
>>>> relevant comments) - or is there some tool to do this with?
>>>> 
>>>> Tim
>>>> 
>>>>> On 18 Mar 2019, at 07:38, Marcus Denker  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> We should all look at the old issues:
>>>>> 
>>>>>   https://pharo.fogbugz.com/f/filters/57/All-newest-first
>>>>> 
>>>>> and move them to the new one:
>>>>> 
>>>>>   https://github.com/pharo-project/pharo/issues
>>>>> 
>>>>> instead of moving them automatically, we should take the chance to
>>>>> clean up.
>>>>> 
>>>>> Please check, first for the issues that *you* added:
>>>>> 
>>>>>   -> is it still relevant?
>>>>>   ->if yes: add a new issue on GitHub 
>>>>>   ->close this issue, there is now an explicit “moved to GitHub” state.
>>>>> 
>>>>> 
>>>>>   Marcus
>>>> 
>>> 
>> 
> 

Re: [Pharo-dev] [Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

[Tim Mackinnon]

Yes - Cyril is a tool meister…. ;)

> On 19 Mar 2019, at 10:08, Marcus Denker  wrote:
> 
> Hi,
> 
> I think Cyril has some kind of tool? Yes, that might be interesting...
> 
>> On 18 Mar 2019, at 19:26, Tim Mackinnon > <mailto:tim@testit.works>> wrote:
>> 
>> Marcus - do we just manually copy over the title and description (and any 
>> relevant comments) - or is there some tool to do this with?
>> 
>> Tim
>> 
>>> On 18 Mar 2019, at 07:38, Marcus Denker >> <mailto:marcus.den...@inria.fr>> wrote:
>>> 
>>> Hi,
>>> 
>>> We should all look at the old issues:
>>> 
>>> https://pharo.fogbugz.com/f/filters/57/All-newest-first 
>>> <https://pharo.fogbugz.com/f/filters/57/All-newest-first>
>>> 
>>> and move them to the new one:
>>> 
>>> https://github.com/pharo-project/pharo/issues 
>>> <https://github.com/pharo-project/pharo/issues>
>>> 
>>> instead of moving them automatically, we should take the chance to
>>> clean up.
>>> 
>>> Please check, first for the issues that *you* added:
>>> 
>>> -> is it still relevant?
>>> ->if yes: add a new issue on GitHub 
>>> ->close this issue, there is now an explicit “moved to GitHub” state.
>>> 
>>> 
>>> Marcus
>> 
> 

Re: [Pharo-dev] [Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

[Tim Mackinnon]

Marcus - do we just manually copy over the title and description (and any 
relevant comments) - or is there some tool to do this with?

Tim

> On 18 Mar 2019, at 07:38, Marcus Denker  wrote:
> 
> Hi,
> 
> We should all look at the old issues:
> 
>   https://pharo.fogbugz.com/f/filters/57/All-newest-first 
> 
> 
> and move them to the new one:
> 
>   https://github.com/pharo-project/pharo/issues 
> 
> 
> instead of moving them automatically, we should take the chance to
> clean up.
> 
> Please check, first for the issues that *you* added:
> 
>   -> is it still relevant?
>   ->if yes: add a new issue on GitHub 
>   ->close this issue, there is now an explicit “moved to GitHub” state.
> 
> 
>   Marcus

Re: [Pharo-dev] Roassal Animations

[Tim Mackinnon]

+10, I’ve loved them them too.

> On 17 Mar 2019, at 19:40, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 17 Mar 2019, at 20:10, Serge Stinckwich  
>> wrote:
>> 
>> Most of the animations are available in the Roassal3 code:
>> 
>> https://github.com/ObjectProfile/Roassal3
> 
> Yes, OK, but maybe there is some webpage somewhere that collects the Twitter 
> posts, they were really good advertisements.
> 
>> On Sun, Mar 17, 2019 at 7:23 PM Sven Van Caekenberghe  wrote:
>> Hi,
>> 
>> Who has seen these Roassal Animations on Twitter recently ?
>> 
>> These are crazy cool and super slick.
>> 
>> Is there a place where they are all collected, maybe with their code ?
>> 
>> Sven
>> 
>> 
>> 
>> 
>> -- 
>> Serge Stinckwic​h​
>> Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO)
>> ​Sorbonne University (SU)
>> French National Research Institute for Sustainable Development (IRD)​
>> U​niversity of Yaoundé I​, Cameroun
>> "Programs must be written for people to read, and only incidentally for 
>> machines to execute."
>> https://twitter.com/SergeStinckwich
>> ​
> 
> 

Re: [Pharo-dev] OSProcess for Pharo 7

[Tim Mackinnon]

Ohh - yeah, I can’t use that as it doesn’t support windows right? (It’s all a 
bit confusing)

Tim

Sent from my iPhone



Sent from my iPhone
> On 14 Mar 2019, at 19:00, ducasse  wrote:
> 
> I was talking about OSSubProcess

Re: [Pharo-dev] OSProcess for Pharo 7

[Tim Mackinnon]

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

> On 14 Mar 2019, at 16:38, ducasse  wrote:
> 
> 
> 
>> On 14 Mar 2019, at 17:33, Max Leske  wrote:
>> 
>> On 13 Mar 2019, at 11:55, ducasse wrote:
>> 
>>> Ok now one of these days we will have to have all the important libraries 
>>> hosted in the same place.
>>> It is not sure that we will maintain MC forever.
>>> For example SmalltalkHub should get readonly by the end of the year (for 
>>> lack of maintenance reason).
>>> BTW is OSSubProcess working for you?
>> 
>> Yes, it works. There appear to be some methods that need to be updated but 
>> general functionality is there.
> 
> Let us know because Guille did a pass on Mariano’s version and we are ready 
> to improve it.
> 
>> 
>> Max
>> 
>>> 
 Hi Stef,
 
 On 11 Mar 2019, at 8:12, ducasse wrote:
 
> Max
> 
> ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal 
> that it got removed in P7. But we should check this.
> I do not have the time today for this.
> 
> normally ifNotNilDo: should be covered by a migrator automatic rewrite 
> rules (can you check?): Ducasse/Migrator
> because in such case you load the migrator packages and execute the tests 
> of the OSProcess (if any)
> then you execute OSProcess and the user of ifNotNilDo: will be 
> automatically rewritten and you are just left to check
> the senders that are left and commit a new version.
 
 You have extensions defined for #ifNotNilDo: in your migration definition 
 for 50 to 60.
 
> 
> If IfNotNilDo: is not covered by a automated migration we should add one.
> It was deprecated before the automated migrations were introduced.
> 
> 
> Now about your question: yes a new version of OSProcess should be 
> produced for P7.
> The best would be to migrate it to github.
 
 I think Dave might disagree ;) If the maintainers are fine with moving to 
 Github then that would be great. I assume that there will be some 
 objections to that (e.g. because of loading in Squeak?) and we (I at 
 least) don't want to maintain a fork / mirror on Github.
 Pulling from SqueakSource works fine for now.
 
 Max
 
> 
> Let me know if it helps.
> 
> Stef
> 
>> On 11 Mar 2019, at 08:00, Max Leske  wrote:
>> 
>> Hi all,
>> 
>> Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading 
>> fails. I volunteer to update OSProcess for Pharo 7 but I need someone to 
>> tell me what the expected workflow is. AFAICT, we've simply copied the 
>> current ConfigurationOf to the MetaRepoForXX in the past without making 
>> any changes specific to Pharo. That will not work this time.
>> So, should I create a new version of OSProcess for all platforms, where 
>> #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a 
>> compatibility package for Pharo? Or something else?
>> 
>> Cheers,
>> Max
>> 
 
>> 
> 
> 
> 

Re: [Pharo-dev] managing modification of class initialization methods

[Tim Mackinnon]

If we go back to where this comes from - I don’t think its so obvious what the 
behaviour is. Newcomers to Smalltalk don’t get it, and I suspect even seasoned 
Smalltalkers have to think twice or more about this.

If we roll back to where I think this question came from:

If I have a simple constant like #maxLimit - I can stick it as an instance 
method as:

maxLimit
^42


But if my constant is more complicated like:

massTable
| multiplier |
multipier := 4.25678.

^{ ‘a’ -> 27 * multiplier.
‘b’ -> 42 * multiplier.
…
‘z’ -> 106 * multiplier } asDictionary

It's not ideal to have this as an instance method - so you are advised to move 
it up to the class level, and try to emulate a “const”.

But this still isn’t good enough as its evaluated every time - so you add a 
class variable MassTable and initialize it once, in class>>initialize

Initialise

MassTable := self massTable.


Ok - so far so good - except you made a mistake and want to correct the value 
for ‘z’, which you change from 106 to 110 and press save.

But surprise, surprise, it doesn’t change - because when is class #initialise 
actually called? Trick question it turns out - as if I make the change in 
GitHub, commit the code and then reload the package with iceberg - it still 
won’t change as reloading code doesn’t cause class initialise (which is 
surprising to most).

I think that this this quite common occurrence shouldn’t be so mysterious - why 
can’t I just change the code, save it and have the value change in some obvious 
manor without some voodoo. This is one of those strange cases of smalltalk 
where it doesn’t obviously do what I expect and I need to know too much of the 
system to do the right thing. 

I think we could come up with a way to make this easier - but It would be good 
to get the wisdom of the crowd in on this.

This is one of the early exercise in Exercism, and we’d like to know the best, 
element, in keeping with the philosophy solution.

At the moment, a class variable with a lazy getter is the suggested solution 
e.g.

massTable
“MyClass MassTable := nil. self massTable >>>”

^MassTable ifNil: [ MassTable :=  self createMassTable ]

Where you have to remember to click on the example icon, or evaluate a doIt is 
the best solution.

To me - this is WTF? Surely we can do better in an environment where we control 
the compiler, ide and interaction model?

Tim



> On 4 Mar 2019, at 16:26, Sven Van Caekenberghe  wrote:
> 
> (1) the basic concepts are clear (and have been for a long time):
> 
> - when a class initialize method is loaded, it is executed afterwards, if and 
> only if the source code changed
> 
> - there are startUp[:] and shutDown[:] and SessionManager to handle images 
> coming up, saving and going down
> 
> With these tools you can build any behaviour you want.
> 
> I am not sure we need something else, except maybe more education
> 
> 
> (2) the problem is much larger than just the class initialize method, since 
> that can call other methods (like #initializeConstants, etc, ..) - even if 
> the class initialize method did not change, a method further down might have 
> and could require re-initialization. 
> 
> For this reason I sometimes put a timestamp in a comment of the class 
> initialize method to force re-initialization since I known that I added a new 
> constant somewhere (much) further down.
> 
> 
> Complex new features might do more harm than good
> 
>> On 4 Mar 2019, at 17:13, Ben Coman  wrote:
>> 
>> 
>> 
>> On Mon, 4 Mar 2019 at 20:08, Norbert Hartl  wrote:
>> 
>> 
>>> Am 04.03.2019 um 03:46 schrieb Ben Coman :
>>> 
>>> In relation to developing sample solutions for an Exercism exercise, the 
>>> following observation was made about class initialization...
>>> 
 class is initialized on load - and not when you modify it - so this can be 
 very confusing for users  
>>> 
>>> My first thought was to wonder if Quality Assistant could track whether a 
>>> class initialize method had been run after it was modified,
>>> and display alerts.
>>> 
>>> Alternatively, I wonder if a reasonable pattern would be to couple 
>>> class-side lazy initialization 
>>> with a pragma to reset a variable when the method is saved...
>>> 
>>>MyClass class >> referenceData
>>>
>>>^ ReferenceData := ReferenceData ifNil: [ 'reference data' ]
>>> 
>> 
>> Isn’t the usual way to do that to register the class in the shutdown list 
>> and implement #shutdown: ?
>> 
>> To me a good minute to work out why I didn't understand you.
>> Sorry, I meant 
>> 
>> So when 'reference data' is updated and the modified method is saved,
>> the variable gets lazy initialized *again* with the new definition. 
>> 
>> hope that is more clear,
>> cheers -ben
> 
> 

Re: [Pharo-dev] managing modification of class initialization methods

[Tim Mackinnon]

He he Ben - I was just coming over here to ask something similar …

It also struck me that a method that initialises a class variable should rerun 
when saved, as the mystery of class side #initialize and when its actually sent 
can be a bit overwhelming.

These days, we have all of the hooks to do this well don’t we? I guess the 
issue comes down to how far you have to go if there are method dependencies 
etc. So yeah - maybe a pragma to make the intent clear might be a nice way to 
go.

As it stands (and where I’m sure this thread comes from) - I think the clarity 
of:

 MyVar ifNil: [MyVar := self bigInitialisation] 

makes it a bit more obvious that its a lazy initialisation and you have to 
re-run it (and I cheat with an example like: “MyClassVar := nil. MyClass 
myClassVarAccessor >>>”)

But I wonder if the lazy initialisation approach is the favoured one anyway - 
and am curious what others think (but still agree with Ben that class 
initialised vars should work better in this day and age).

Tim

> On 4 Mar 2019, at 02:46, Ben Coman  wrote:
> 
> In relation to developing sample solutions for an Exercism exercise, the 
> following observation was made about class initialization...
> 
>> class is initialized on load - and not when you modify it - so this can be 
>> very confusing for users  
> 
> My first thought was to wonder if Quality Assistant could track whether a 
> class initialize method had been run after it was modified,
> and display alerts.
> 
> Alternatively, I wonder if a reasonable pattern would be to couple class-side 
> lazy initialization 
> with a pragma to reset a variable when the method is saved...
> 
>MyClass class >> referenceData
>
>^ ReferenceData := ReferenceData ifNil: [ 'reference data' ]
> 
> cheers -ben

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

[Tim Mackinnon]

Nice bit of detective work !

Sent from my iPhone

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

Re: [Pharo-dev] [Pharo-users] About Iceberg

[Tim Mackinnon]

Yes I agree - when there is so much discussion and debate going on, its easy to 
lose sight of the hard work and determination that went into getting us to this 
brave new world. I too want to shout a big thank you for the tooling and also 
the support that goes along with that.

I love been able to think a bit more polyglot, and use tools/languages more 
easily side by side - although of course I want to hold on to what makes 
Smalltalk special (which is tons of stuff).

I particularly love being able to feel like its easier to contribute - updating 
readme’s and docs is trivial in a web browser now - just correct them and 
submit a PR. And on the receiving side - GitHub makes it easy to discuss the 
fix, alter it, or simply approve it. Equally - modern build tools easily detect 
the change, pull the code and rebuild and package it (and cheap scalable 
infrastructure).

Its also getting easier and easier to submit code fixes too - and the VCS 
skills you learn doing this are transferable beyond Smalltalk - so its a big 
win win.

So yes guys - thanks for hanging in for us!

Tim

> On 19 Feb 2019, at 08:50, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> This is a thank you note about Iceberg.
> 
> I have been moving all my external and internal Pharo code to git/tonel/7 and 
> on multiple occasions I have been pleasantly surprised about the 
> functionality and performance of Iceberg. Basically, it just works.
> 
> Finally, Pharo code lives in standard open source and commercial repositories 
> (git, GitHub, Bitbucket, ...), without losing anything.
> 
> I know that it took years to get here and that lots of code and community 
> battles had to be fought. So thank you, to the whole team, you did a great 
> job !
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 
> 

Re: [Pharo-dev] The HiDPI Issue

[Tim Mackinnon]

Eric - I had the same feeling a few years ago when I got a retina laptop and 
found Pharo a bit fuzzy on the eyes (although it’s true that with time you 
start to notice it less).

Anyway - I’m not sure anyone has actually mentioned that you can download the 
latest Glamourous Toolkit (https://gtoolkit.com/#install 
 - take the prebuilt image) and then open a 
playground (with all other windows closed) and evaluate:

Bloc preferableHostClass: BlOSWindowHost

Then try one of the examples in the GT menu (don’t go full screen in your 
image), and this will open a second native window rendered in retina quality. 
Its still a bit alpha - you get a warning dialog that you have to click ignore 
on 3 times - but then it keeps running. It is also obviously unoptimised at 
this point too.

I think this gives a welcome glance of the future - so there is hope.

Tim

> On 16 Feb 2019, at 11:04, ducasse  wrote:
> 
> Hi Eric
> 
> I will let esteban reply carefully :)
> Now my take on this is 
>   that we want to go via SDL and other backends to solve the problems 
> (event dropping, display)
>   Back in October, Esteban fixed the SDL/OSWindows so that Bloc people 
> can get rid of the 
>   VM rendering and be free. 
> 
> This is the path to go. 
> For Bloc I (personally and discussing with Alain) think that there is 4-6 
> months of work (if I would overselling it I would have said that this is 2 
> month work) to clean it and tight it up - (not talking about Widgets). I 
> personnally do not want Design like Glamour or GT in the system (too many 
> announcers).
> So we will take time to do real code review. 
> 
> So our roadmap is 
>   - make sure that Pharo can work headless
>   - check the impact of SDL/OSWindow
>   - focus on new spec version so that we can have our tools migrated and 
> we do not have to 
>   rewrite them once more. 
>   
> Pharo 90 probably focus on Bloc. 
> 
> 
> Stef
> 
>> On 15 Feb 2019, at 17:52, Eric Gade  wrote:
>> 
>> Hello,
>> 
>> I know that others have posted about this before but I wanted to get the 
>> current status. 
>> 
>> I've recently had to buy a new laptop that came with a HiDPI display. 
>> Generally (especially on Linux systems) this makes Pharo unusable. Though 
>> there are font size increase and scaling options in the Pharo system 
>> settings, these do not work as a solution -- buttons are still tiny, there 
>> is inconsistent scaling behavior across morphic, etc. The overall problem 
>> can be described as: in Pharo, one pixel equals one "point," and so the 
>> interface is incredibly small on these HiDPI screens (3k etc).
>> 
>> These HiDPI screens are becoming more common, both as laptop and as external 
>> displays. Their main advantage is that they can render text very crisply. In 
>> the HN post announcing the release of P7, there were one or two complaints 
>> about this issue. It does make it hard to demonstrate to others (as I do 
>> often) the power of developing in Pharo.
>> 
>> Here are some questions I have about this issue:
>> 1) What is the current state of affairs in dealing with this issue, if any?
>> 2) Would this require VM changes (I assume it would)? If so, what might 
>> those entail?
>> 3) If this does require VM changes, I assume the Squeak people would want in 
>> on it?
>> 4) Is the current plan to wait for Bloc to resolve these issues and/or would 
>> switching to Bloc resolve these issues at all anyway?
>> 5) Related -- where can one start to learn about current VM architecture and 
>> development practices?
>> 
>> That said I'm not here to just bellyache. While I don't have any VM 
>> experience, I'm willing to jump in and try to work on it if someone can 
>> point me in the right direction. Or perhaps this is too specialized a task...
>> 
>> Thanks
>> 
>> -- 
>> Eric
> 
> 
> 

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Tim Mackinnon]

+1 (with proviso there is that minimal image you can use to build up from)

> On 8 Feb 2019, at 15:57, Norbert Hartl  wrote:
> 
> 
> 
>> Am 08.02.2019 um 16:47 schrieb Serge Stinckwich > >:
>> 
>> 
>> 
>> On Fri, Feb 8, 2019 at 4:41 PM Alexandre Bergel via Pharo-dev 
>> mailto:pharo-dev@lists.pharo.org>> wrote:
>> Dear All,
>> 
>> At the consortium meeting we discussed the possibility to have a 
>> mini-Roassal included in Pharo8. Many opportunities exist: displaying graph 
>> of commits in iceberg, displaying UML within the code browser, visualizing 
>> dependencies between packages.
>> 
>> We are motivated about it, and we should produce a runnable proposal ready 
>> to be evaluated by the community within a couple of months. 
>> Does it make sense? Any thought about it? Do you have a wishlist?
>> 
>> 
>> I will not be be strongly against it because I see benefits, but IHMO we 
>> need to reduce the size of Pharo image.
>> Might be interesting to have charts included in the base.
>> A+
>> 
> I don’t agree. Why should we reduce the size of the default image? It should 
> show a lot of things you can do with pharo. As everything is loaded from 
> bootstrap we can have now every size of the image we want. I would rather see 
> an official minimal image that people will download for building their 
> software. But the development should contain everything that eases 
> development and shows what pharo can do.
> The critical border to me is what we provide in documentation. On the one 
> hand we could benefit from powerful code documentation. But this could 
> conflict with the minimum image we provide where people work on and these 
> tools would be missing.
> 
> Norbert
> 
>> -- 
>> Serge Stinckwich
>> Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO)
>> Sorbonne University (SU)
>> French National Research Institute for Sustainable Development (IRD)
>> University of Yaoundé I, Cameroun
>> "Programs must be written for people to read, and only incidentally for 
>> machines to execute."
>> https://twitter.com/SergeStinckwich 
> 

Re: [Pharo-dev] [Pharo-users] New book: Pharo with Style

[Tim Mackinnon via Pharo-dev]

--- Begin Message ---
I’ve always felt the XP book nailed it - don’t use comments as a crutch to 
avoid fixing confusing code and don’t do work twice by simply writing a comment 
that says the same as the code. (You can of course try to write the comment and 
auto-generate the code, but we’ve tried that before).

Smalltalk is an expressive language that should read like comments naturally - 
both with the name of a method, the variables and the statements in it.

This leaves comments as a good place to tell a story about the wider context 
and where to look to get started or learn more. I think this is possibly where 
Documentor is going to help you navigate along the real code.

Of course if after all of this you can’t figure out how to fix the code - then 
a comment is a good last resort.

Tim 
Sent from my iPhone

> On 1 Jan 2019, at 12:43, Alistair Grant  wrote:
> 
> Hi Richard,
> 
>> On Tue, 1 Jan 2019 at 07:26, Richard O'Keefe  wrote:
>> 
>> ...
>> 
>> To get an example, I did (String allSelectors atRandom), getting
>> #copyWithoutAll:.  That has only one definition, in Collection:
>>   copyWithoutAll: aCollection
>> "Answer a copy of the receiver that does not contain any elements
>> equal to those in aCollection."
>> 
>> ^ self reject: [:each | aCollection includes: each]
>> 
>> The comment simply paraphrases the rather simple code.
> 
> I agree with pretty much everything you've written, but have a
> slightly different view here.
> 
> Including what the method does, even when the code is fairly simple
> (OK, not getter / setter methods), is still useful.  If the comment is
> absent, I have to look at the code, figure out what it does, and then
> either figure out if that's what it is supposed to do, or just assume
> that I'm correct.  Having to figure out whether I've interpreted the
> code correctly just increases the cognitive load.  If the comment
> includes what it is supposed to do, I have a context in which to read
> and evaluate the code, and it becomes much less effort.
> 
> Cheers,
> Alistair
> 


--- End Message ---

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

[Tim Mackinnon via Pharo-dev]

--- Begin Message ---
Ah - so is the HANDLER variable set via the AWS console? (If so, then I’d agree 
that using the env var makes more sense).

It also sounds like NeoJson makes sense for the mapping - I hadn’t needed it 
before in my usage - I don’t think it’s very heavy weight anyway. For 
debugging, the serialisation of the stack to a bucket is so cool (kudos to Fuel 
for that), but cloudwatch is a useful basic tool and it does let you hook up to 
things like data dog etc. so we fit easily into the cloud eco system.

I need to get things up and running again and will report back.

Thanks again.

Tim

Sent from my iPhone

> On 28 Dec 2018, at 17:30, Jan van de Sandt  wrote:
> 
> Hi Tim,
> 
>> On Fri, Dec 28, 2018 at 4:49 PM Tim Mackinnon  wrote:
>> Hi Jan - reading through your docs, this looks very promising as I hadn’t 
>> got as far as using the api gateway - I was just connecting to the internal 
>> Alexa service.
>> 
>> One thing I didn’t quite understand - you mention specifying a HANDLER as an 
>> env variable, but your example description doesn’t seem to show where that 
>> is set? Is it in the bootstrap file (also is that bootrap.sh or just simply 
>> bootstrap?
> 
> Up til now I have configured my Lambda functions mostly via the AWS Console. 
> When you create your function you must upload your code, specify the type of 
> runtime and give the name of the handler. For a Java runtime this is the name 
> of the main class, so for the Smalltalk implementation I choose something 
> similar. If you want you can leave this item empty or set it to "Provided" 
> and just hardcode the startup class in the image or in the bootstrap file. 
> 
>> And are there any file attributes to set on that file?). It strikes me that 
>> rather than using an env variable - why don’t you specify the handler class 
>> when you invoke the image as the last command line option? (That is what I 
>> did in my example - or is it faster to query an env variable? Personally I 
>> find it easier to see it more explicitly on the command line).
>> 
>> I also notice you include NeoJson - did you need that? I found that the 
>> default Ston reader was more than adequate for reading the json  that was 
>> sent over (and so it’s one less pre-req).
>> 
> With NeoJSON you can create mappings to serialize/deserialize custom 
> Smalltalk classes to Json. I use this functionality in the CloudWatch-Logs 
> interface to handle the request and response objects. I don't think this is 
> possible with STON.
>  
>> I haven’t yet fully understood the runtime layer - is this simply a zip file 
>> with the vm + files and without the image? Previously I had to add all of 
>> that in the zip I uploaded for each function, but this sounds like it 
>> simplifies things a lot. Do you have a script you used to create that - I 
>> ask as I found that trimming down the size of that made a difference to load 
>> times for Alexa (eg there are lots of sound and graphics dll’s you can 
>> remove - which I have in my script, and possibly, I could add to what you 
>> have done).
> 
> Yes, the layers are a great new feature. My layer just includes a standard 
> Pharo 64 bits VM without any additions or removals. I made this one by hand, 
> a script would be a better idea! You can remove shared libraries that you 
> don't need. I think the most important thing is that the image does not 
> load/initialize any unnecessary libraries. 
>> 
>> Equally, I also figured out the command line fu for uploading and 
>> registering your Lamba so it works in a ci - this might also be worthy of 
>> inclusion.
>> 
> Yes, a CI job that can build a 'deployment' image and that can upload this 
> image to AWS Lambda would be a great feature!
>  
>> Anyway, l’ll Give it a go and see how the results compare - it was 
>> surprisingly fast using the js shim - but this seems like a much better 
>> solution.
>> 
>> Thanks for sharing - it’s an executing world.
>> 
>> Tim
>> 
> Thanks for your comments!
> Jan.
>  
>> 
>> 
>> 
>> Sent from my iPhone
>>> On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote:
>>> Hi Tim,
>>> 
>>> Yes, I read that you got Pharo working via the Javascript runtime. It 
>>> should now be much easier and faster.
>>> 
>>> I still have to figure out the best way to create a deployment image. With 
>>> the new bootstrap/modular setup of Pharo 7 it should be possible to create 
>>> a lean-and-mean runtime image that can run in the cheapest 128MB max. ram 
>>> configuration.
>>> 
>>> Jan.

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

[Tim Mackinnon]

Hi Jan - reading through your docs, this looks very promising as I hadn’t got 
as far as using the api gateway - I was just connecting to the internal Alexa 
service.

One thing I didn’t quite understand - you mention specifying a HANDLER as an 
env variable, but your example description doesn’t seem to show where that is 
set? Is it in the bootstrap file (also is that bootrap.sh or just simply 
bootstrap? And are there any file attributes to set on that file?). It strikes 
me that rather than using an env variable - why don’t you specify the handler 
class when you invoke the image as the last command line option? (That is what 
I did in my example - or is it faster to query an env variable? Personally I 
find it easier to see it more explicitly on the command line).

I also notice you include NeoJson - did you need that? I found that the default 
Ston reader was more than adequate for reading the json  that was sent over 
(and so it’s one less pre-req).

I haven’t yet fully understood the runtime layer - is this simply a zip file 
with the vm + files and without the image? Previously I had to add all of that 
in the zip I uploaded for each function, but this sounds like it simplifies 
things a lot. Do you have a script you used to create that - I ask as I found 
that trimming down the size of that made a difference to load times for Alexa 
(eg there are lots of sound and graphics dll’s you can remove - which I have in 
my script, and possibley, I could add to what you have done).

Equally, I also figured out the command line fu for uploading and registering 
your Lamba so it works in a ci - this might also be worthy of inclusion.

Anyway, l’ll Give it a go and see how the results compare - it was surprisingly 
fast using the js shim - but this seems like a much better solution.

Thanks for sharing - it’s an executing world.

Tim




Sent from my iPhone
> On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote:
> Hi Tim,
> 
> Yes, I read that you got Pharo working via the Javascript runtime. It should 
> now be much easier and faster.
> 
> I still have to figure out the best way to create a deployment image. With 
> the new bootstrap/modular setup of Pharo 7 it should be possible to create a 
> lean-and-mean runtime image that can run in the cheapest 128MB max. ram 
> configuration.
> 
> Jan.
> 
> On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon  wrote:
> Cool - I was using a JS shim and had asked AWS many times why they couldn’t 
> open it up wider... 
> 
> Now I’m back from my travels I’ll reincarnate my previous work and see how it 
> works with this. I was looking forward to doing more with Lambda, so this is 
> great timing.
> 
>  Tim
> 
> Sent from my iPhone
> 
>> On 27 Dec 2018, at 10:32, Jan van de Sandt  wrote:
>> Hi,
>> 
>> Last month Amazon extended their serverless runtime platform AWS Lambda with 
>> support for custom runtimes. I created a Pharo Lambda Runtime so now we can 
>> implement Lambda functions in Smalltalk and easily deploy them on the Lambda 
>> platform. Lamba has quite a large "free-tier", more than enough to do some 
>> experiments and to host small applications for free.
>> 
>> See the GitHub project for more details 
>> https://github.com/jvdsandt/pharo-aws-toolbox
>> 
>> Cheers,
>> Jan.

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

[Tim Mackinnon]

Cool - I was using a JS shim and had asked AWS many times why they couldn’t 
open it up wider... 

Now I’m back from my travels I’ll reincarnate my previous work and see how it 
works with this. I was looking forward to doing more with Lambda, so this is 
great timing.

 Tim

Sent from my iPhone

> On 27 Dec 2018, at 10:32, Jan van de Sandt  wrote:
> 
> Hi,
> 
> Last month Amazon extended their serverless runtime platform AWS Lambda with 
> support for custom runtimes. I created a Pharo Lambda Runtime so now we can 
> implement Lambda functions in Smalltalk and easily deploy them on the Lambda 
> platform. Lamba has quite a large "free-tier", more than enough to do some 
> experiments and to host small applications for free.
> 
> See the GitHub project for more details 
> https://github.com/jvdsandt/pharo-aws-toolbox
> 
> Cheers,
> Jan.

Re: [Pharo-dev] Application entrypoints

[Tim Mackinnon]

Actually - kind of related, how does one know how to reset a framework like 
Seaside, or Zinc etc.

I’ve been thinking about proposing frameworks should have a #reset like pragma 
and then the system menu could find them and show the reset menu for all 
frameworks that provide it. I think applications could do a similar thing - 
have an #applicationStart pragma and then there could be an applications menu 
that listed them all in a convenient menu.

Tim

Sent from my iPhone

> On 13 Dec 2018, at 08:38, nanqueti  wrote:
> 
> 
> we could also use the "script:" annotation, and the system browser
> could show it at the class level (it already shows at the method level)
> 
> nicolas
> 
>> On Thu, 2018-12-13 at 10:40 +0800, Ben Coman wrote:
>> A question was asked on discord... "I know how to start the lights
>> out example, 
>> and feed my objects test data with the testing framework, but how
>> does one start 
>> something like ChineseCheckers? How does one find the entry point? 
>> Is there a convention on naming a starting place?"
>> 
>> I remember having similar thoughts when starting in Pharo.
>> 
>> One convention I have seen is that amongst all the classes presumably
>> prefixed "CC"
>> one class would stand out being named for the application without the
>> prefix. 
>> e.g. class "ChineseCheckers".  That is only a narrow chance for a
>> namespace conflict,
>> the the risk still remains.
>> 
>> I suggested another path would have a package tag "Application" 
>> (i.e. "ChineseCheckers-Application") that contains a single class 
>> which has an #open method on the class-side.
>> The tag "Application" sorts high up on the package-tags and is self-
>> descriptive.
>> But I've not seen that used before, so while I think its a good idea,
>> its not really a convention. 
>> Conventions are only useful if they are broadly understood.
>> 
>> So I'm wondering what other things people do to draw attention to
>> their application entry points.  
>> 
>> cheers -ben
> -- 
> Nicolas Anquetil
> RMod team -- Inria Lille
> 
> 

Re: [Pharo-dev] periodic auto actions on bug tracker

[Tim Mackinnon]

It’s a great idea - I too have a good look at what I previously reported and 
decide if it’s still relevant and whether it makes sense to still pursue it.

Sent from my iPhone

> On 9 Dec 2018, at 06:20, Ben Coman  wrote:
> 
> I support the auto-closing of old tickets to avoid bug bankruptcy.  Sometimes 
> things seem more important at the time and when my own tickets come back 
> around I get to be more analytical about the effort/reward balance.
> 
> It would be useful to expand this a bit to have a quarterly mail out saying 
> something like "Is this issue still important to you?  Try socializing it on 
> the pharo-dev mail list.  Issues going twelve months without interaction will 
> be auto-closed".  Then its not a bad surprise to new users when their ticket 
> is auto-closed.
> 
> cheers -ben
> 
> 

Re: [Pharo-dev] [Pharo-users] Fwd: Announcing Repl.it Multiplayer

[Tim Mackinnon]

There was also the work that Jason and Julien did with “Wolfpack” (this was in 
VisualWorks) that explores the idea of group programming in an image. They did 
quite a few workshops on it, and it was tantalisingly interesting but I think 
they ran out of steam.

Tim

Sent from my iPhone

> On 7 Dec 2018, at 06:34, Ben Coman  wrote:
> 
> One advantage of their seemingly text-based system might be bandwidth, but 
> Pharo is a graphical system.
> It might be worthwhile for dispersed teams working on web hosted Pharo 
> systems, but we already have remote tools.  
> I guess it might almost already be able to have multiple people using them 
> simultaneously on the one image(?), but everyone would be looking at 
> different Inpectors.
> It could be cool for a common Inspector instance to show up on multiple user 
> screens.
> But is it that much better than the other suggestions??
> 
> cheers -ben
> 
>> On Fri, 7 Dec 2018 at 06:03, Eliot Miranda  wrote:
>> Hi Santiago,
>> 
>>> On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo 
>>>  wrote:
>>> Would this be interesting to have in pharo??
>> 
>> There is already previous relevant work.  Look up Kansas for Self 
>> http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak 
>> http://wiki.squeak.org/squeak/1356.  Focussing on the Multiplayer like UI 
>> would be a major regression.  Note that we already have lots fo relevant 
>> infrastructure, such as a VNC server that allows desktops to be shared.  
>> Building a shared programming environment for Pharo doesn't need to start 
>> from such limited models as the Multiplayer.
>>  
>>> 
>>> What do you think?
>>> 
>>> -- Forwarded message -
>>> From: Amjad from Repl.it 
>>> Date: jue., 6 de dic. de 2018 21:55
>>> Subject: Announcing Repl.it Multiplayer
>>> To: 
>>> 
>>> 
>>>  
>>> Hey Santiago, 
>>> 
>>> Professional programmers all know that software development is a 
>>> fundamentally social experience. But coding remains a single-player 
>>> experience by default — today, we're changing this!
>>> 
>>> As part of our mission to make computing more accessible, we believe 
>>> connecting coders, learners, and teachers together in real time, in the 
>>> development environment, is a big piece of the puzzle. That's why we're 
>>> proud to announce Multiplayer.
>>> 
>>> Multiplayer lets you code with friends in the same editor, execute programs 
>>> in the same interpreter, interact with the same terminal, chat in the IDE, 
>>> edit files and share the same system resources, and ship applications from 
>>> the same interface! We've redesigned every part of our infrastructure to 
>>> work in multiplayer mode -- from the filesystem to the interpreter.
>>> 
>>> Read more about it here, or, better yet, hop in, invite your friends and 
>>> start coding!
>>> Amjad from Repl.it
>>> 
>>> 767 Bryant St, #210, San Francisco, CA 94107
>>> 
>>> Unsubscribe - Unsubscribe Preferences
>>> 
>>> 
>> 
>> 
>> -- 
>> _,,,^..^,,,_
>> best, Eliot

Re: [Pharo-dev] [Pharo-users] glamorous toolkit alpha.3

[Tim Mackinnon]

It’s very exciting watching the progress both in these email updates and the 
excellent more visual tweets.

This and the progress on Pharo 7 will make for a great Xmas!

Tim

Sent from my iPhone

> On 20 Nov 2018, at 23:08, Tudor Girba  wrote:
> 
> Hi,
> 
> Another month has swooshed and now it’s time for Glamorous Toolkit alpha.3:
> https://feenk.com/gt
> 
> The key things that changed are as follows:
> 
> - We rewrote Documenter. This was challenge, but the results are more than 
> worth it. 
> One visible thing is that now the previews get cached, and as a consequence 
> we can actually work inside the document. 
> But, perhaps the more impactful thing is that we can now toggle the 
> visibility of Pillar markup. We think it significantly improves the 
> experience and consequently, the value of the live documents.
> 
> 
> 
> 
> - We advanced the work on the method Coder. To explore the boundaries, we 
> reimagined the extract method refactoring. That’s :
> https://twitter.com/feenkcom/status/1064823381407748096
> 
> - We enhanced the navigation in Playground / Inspector:
> https://twitter.com/feenkcom/status/1064823381407748096
> 
> 
> A more complete list of issues we addressed is found here:
> https://github.com/feenkcom/gtoolkit/milestone/1?closed=1
> 
> 
> 
> Have fun,
> The feenk team
> 
> --
> www.feenk.com
> 
> “How do you feenk today?"
> 

Re: [Pharo-dev] Anyone else seen crashes like these ?

[Tim Mackinnon]

You didn’t say it, but I think implied that this is new to P7? I don’t get it 
on P6, and haven’t noticed it in earlier P7 images. But haven’t extensively 
used a newer P7 image.

Tim

Sent from my iPhone

> On 12 Nov 2018, at 21:47, Cyril Ferlicot  wrote:
> 
>> On Mon, Nov 12, 2018 at 2:37 PM Sven Van Caekenberghe  wrote:
>> 
>> Hi,
>> 
>> I run Pharo 7 64-bit on a macOS laptop, where the images are kept running 
>> across sleep/wake cycles.
>> 
>> For many weeks, it often happens that an image crashes before/after such a 
>> sleep/wakeup (not all the time, just regularly).
>> 
>> Here is a crash dump from today (fresh image/vm from WE, nothing special 
>> loaded).
>> 
>> Related to scheduling ? Event handling ?
>> 
> 
> Hi,
> 
> I switched to an macOS at the beginning of October and since I often
> have this kind of behavior.
> 
>> 
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Tim Mackinnon]

It’s a tricky trade off as Norbert alludes too - in my recent example I needed 
some underlying base pieces in place (for the compiler’s ast) and those needed 
reviewing to then be committed - then there were two parts to Calypso that 
relied on those changes) that also needed reviewing and I wasn’t sure if Denis 
waited for the core approval or loaded up my PR - but anyway it took him a bit 
of time to process that and he came back with some better suggestions that I 
also needed to implement (which I had to find time to do as well).

When I noticed that the core Pharo pieces were merged, I then had to chase 
Denis to see if he was now happy and could merge my changes.

I guess it would be helpful if there was a way to easily load up multiple 
project pr’s in one go (like the suggested slice concept) so maintainers can 
easily review.  Probably more importantly is an easy way to track the status of 
multiple submissions so you can follow up with relevant people and push things 
along and also ensure things get committed in the right order (eg doc the 
dependency chain a bit better).

For me, after a few days I forgot about my Calypso changes and realised a few 
weeks later (by accident) and so could chase Denis.

I think it’s this latter case that Steph alludes to - you lose interest after a 
few days without some useful prompts and easy status tracking. If we can make 
that easier I think it would help.

Tim

Sent from my iPhone

> On 7 Nov 2018, at 05:48, Ben Coman  wrote:
> 
> I get the feeling what is needed is mirroring all dependent repos from
> the canonical location under http://github.com/pharo-project
> and a Slice-like tool (probably keeping the name "Slice") which...
> 1. Pulls all dependent repos to the local machine
> 2. Simultaneously commits to the local repos with the same commit message
> 3. Updates a bootstrap-configuration file holding commit-hashes of all
> the dependencies and commits with same commit message
> 4. Pushes that bootstrap-configuration file and all changed dependent
> repos to user's github account
> 5. Issues a pull request for the bootstrap-configuration file
> 6. Our CI then builds a test-image by commit-hash direct from each
> user's repo and if it passes, pulls dependent repo commits under
> pharo-project
> 7. CI can then issue PRs to the dependency canonical repos
> 
> cheers -ben
> 
>> On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse  
>> wrote:
>> 
>> Calypso is integral part of Pharo as Iceberg.
>> We started to discuss the problem in the team. Right now this project
>> spread kills us.
>> 
>> Stef
>>> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont  wrote:
>>> 
>>> Tim Mackinnon  wrote:
>>>> 
>>> 
>>>> In retrospect,  I’m wondering if successful projects that have proved
>>>> integration usefulness should be moved into the core repo?
>>>> (Iceberg/Calypso?) or are we missing something to help easily track the
>>>> journey of a multi faceted change (although this sounds overkill?). Or
>>>> are there sprint days to try and knock these things through easily with
>>>> everyone on board to do it together?
>>>> 
>>>> We are sort of damned if you do and damned if you don’t. But certainly we
>>>> want to endure that progress can be made without losing the will to 
>>>> contribute.
>>>> 
>>> 
>>> Indeed. Putting things in one repo cannot scale and cannot be a solution
>>> for something that is neither core pharo nor an application. I encourage
>>> everyone who wants to get a good description of this problem to read
>>> 
>>> "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration
>>> Management, and Product Data Management" by Peter van den Hamer & Kees
>>> Lepoeter.
>>> 
>>> With git and github a solution to decouple fast-moving from slow-moving
>>> projects seems to be indeed to fork and make PRs.
>>> That only works if the quality of the PRs is high enough and we manage to
>>> use the feedback from slower-moving projects well.
>>> 
>>> Earlier, we’ve seen projects like Magma being overwhelmed by the number of
>>> needed changes, and Pier being broken by Pillar not respecting its
>>> constraints.
>>> 
>>> With tools like Travis, it is quickly clear if a PR would result in a green
>>> build in the original repo.
>>> 
>>> With projects where Pharo uses only the core, and applications use more
>>> than that, the applications still have a dependency problem: if the core
>>> changes in Pharo influence the other parts, someone needs to do 

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Tim Mackinnon]

Yes this is an emerging problem - I had a similar thing trying to add better 
navigation support to pharo7 as my change touched core and Calypso, so you had 
to get something into core and then loop back to get it approved in Calypso (a 
few weeks later).

In retrospect,  I’m wondering if successful projects that have proved 
integration usefulness should be moved into the core repo? (Iceberg/Calypso?) 
or are we missing something to help easily track the journey of a multi faceted 
change (although this sounds overkill?). Or are there sprint days to try and 
knock these things through easily with everyone on board to do it together?

We are sort of damned if you do and damned if you don’t. But certainly we want 
to endure that progress can be made without losing the will to contribute.

Tim

Sent from my iPhone

> On 4 Nov 2018, at 22:35, Stephane Ducasse  wrote:
> 
> Just to share my pain with you. Try to change something in the API of 
> Commander?
> I think that it will be nearly impossible.
> Because Iceberg/Calypso depend on Commander and they are all managed
> in different repositories.
> So it means
> - fork each
> - probably introduce automatic deprecation
> - do a PR for each of the subprojects (it means identify for each one
> if we should work on dev or master and being able to checkout
> the correct version which is not always possible)
> - then waits.that may be each of the PR got integrated
> - now you lost total focus
> - if one day you recover what you were doing then and only then you
> may finish your change.
> 
> Good luck.
> 
> So to me the message is clear: stay away.
> And this is what I'm doing.
> We are damaging our agility on the altar of a pseudo modularity.
> 
> So this is why I will focus on my tiny, uninteresting side projects.
> Stef
>> On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse  
>> wrote:
>> 
>> Hi Sven
>> 
>> I agree with you. Ideally we would like to have much better tooling
>> and process.
>> Now the last time we discussed with Guille and Pablo about it: they
>> estimated that this is over one year of work.
>> And right now we do not have this engineering time to invest on this
>> because other fronts need to be addressed.
>> Still this is really slowing us. This is simple: I stopped thinking to
>> improve something that touches external packages.
>> So I will not work on the trivial changes that would improve Calypso/Iceberg.
>> Why? Because this is tedious, boring, not rewarding.
>> So yes we can do easily with iceberg simple fix on not external
>> packages but as soon as
>> - you need to load latest dev version (which can be a different one
>> than the current one)
>> - update your repo
>> - fix
>> - do a PR
>> -  wait for its integration
>> 
>> So at the end we as a community can ask ourselves what is the reward
>> model for such shitty work?
>> And also what are we ready to give so that Pharo maintainers do such boring 
>> job.
>> 
>> Right now without really doing it consciously I see myself doing
>> either stupid fix or working on side projects
>> and this is not a good long term approach because the core of Pharo
>> needs a lot of work.
>> 
>> Stef
>>> On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe  wrote:
>>> 
>>> 
>>> 
 On 2 Nov 2018, at 12:01, Norbert Hartl  wrote:
 
 Hi
 
> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse :
> 
> Hi
> 
> Pay attention the following email is not nice and politically correct
> but it is important for the speed of improvements in Pharo.
> 
 thanks for the disclaimer. It is important. I copy that because mine might 
 be not political correct, too.
 
> I think that we are doing our best when dealing with subproject code.
> Now if we are forced to publish each little changes
> on each subproject and wait that something gets integrated into each
> subproject, then I would prefer to stop Pharo and do something else.
> We cannot ask someone to stop in the middle of a massive super boring
> and feel like shit cleaning in addition to stop and
> please publish a PR and wait that it gets integrated and wait that
> Pharo integrates the new version.
> Let us be a bit serious and pro here.
> 
 I know this. And I’m taking it serious because I want to talk about it. If 
 you decide that you rather be offended then talk please do. I find it 
 annoying that a lot of topics are washed away because someone is offended. 
 That is just another way of killing communication although it is a 
 state-of-the-art these days.
 
> Or we should drop subprojects. Because changing Pharo is getting a
> painful. Imagine just a change cross cutting several subprojects.
> For example, I did not fix the use of deprecated classes in Iceberg
> because I got distracted by the where is the project hosted and I was
> not connected on a good web connection. I changed calypso and
> published to calypso but if 

Re: [Pharo-dev] Debugger should step silently over #halt

[Tim Mackinnon]

I never knew it did that - but it makes sense. Presumably pressing resume then 
activated them again right?

Tim

Sent from my iPhone

> On 20 Sep 2018, at 08:42, Ben Coman  wrote:
> 
> I'll often put several breakpoints in code like this...
> ```
> debug := true.
> "Somewhere else in application code..."
> debug ifTrue: [ self halt ].
> 1 + 1. "Representing some longer bit of application code"
> debug ifTrue: [ self halt ].
> 2 + 2. "Representing some longer bit of application code"
> debug ifTrue: [ self halt ].
> 3 + 3. "Representing some longer bit of application code"
> ```
> While stepping  code after hitting the first halt,  
> I am used to subsequent halts being silently stepped over.  
> I just confirmed this with http://files.pharo.org/platform/Pharo6.0-win.zip
> and also build 60541 started from PharoLauncher.
> 
> However build 71231 and build 60542 do not silently step over a #halt.
> Each produces slightly different results (pics attached).
> 
> 
> 
> I've logged an issue...
> https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-halt
> 
> cheers -ben

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

[Tim Mackinnon]

Kind of related - we did get the ability to save methods with undefined classes 
and undeclared variables (vs having to correct this to save). So at least a nod 
to that?

Tim

Sent from my iPhone

> On 13 Sep 2018, at 08:22, Guillermo Polito  wrote:
> 
> Well it's just a matter of stability, we were too concentrated with other 
> stuff.
> But I fear that this would be a too disrupting change to apply now in Pharo 
> 7...
> 
> We were thinking that our focus before the release should be:
>  - fix the important bugs out there (so, everybody, please raise/report your 
> issues :))
>  - iterate on Calypso a bit more so we fix some usability glitches
> 
>> On Thu, Sep 13, 2018 at 4:58 PM Esteban Lorenzano  
>> wrote:
>> We didn't have the time to work on it.
>> It is still part of the roadmap (since we need it to dream with a nice 
>> module system), but it will probably arrive in P8.
>> 
>> Esteban
>> 
>>> On Thu, Sep 13, 2018 at 4:51 PM Torsten Bergmann  wrote:
>>> 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.
>>> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

Re: [Pharo-dev] [update 6.1] #60542

[Tim Mackinnon]

Hi Marcus - does this mean that a fresh zero conf of 6.1 will have the variable 
undeclared change? If so - then I should remove my port of your fix into what I 
load into exercism.

This does raise an interesting question - is there a way to get a fixed 6.1 
version (like a tag) - so that I don’t always have to retest if stuff gets 
ported? (e.g. have a known tagged version that will work until I retest with 
later back ports?)

Tim

> On 17 Aug 2018, at 07:55, Marcus Denker  wrote:
> 
> 60542
> -
> 
> 22305 Backport to Pharo6: "Leave Variable Undeclared"
>   https://pharo.fogbugz.com/f/cases/22305 
> 
>  
> 22298 Backport of the fix of Infinite Debugger
>   https://pharo.fogbugz.com/f/cases/22298 
> 
> 

Re: [Pharo-dev] debugger "Step Out"

[Tim Mackinnon]

When “step-through” was added, that was a lifesaver as we have many block 
iterations. 

Step out would also be a few less clicks than run to curser ... so it sounds 
complimentary.

Tim

Sent from my iPhone

> On 10 Aug 2018, at 04:12, Ben Coman  wrote:
> 
> A very quick note because its hardly important so I know I'll forget it.
> 
> Using MSVC recently and jumping back in the Pharo debugger
> I had a moment when I missing their "Step Out" debugger feature.
> 
> Probably less important in Pharo where we tend to have shorter methods,
> and you can always select up the stack and "Step Over",
> but while I was in-the-flow "Step Out" was what the thing I wanted.
> 
> Anyway, just sharing the thought.  
> 
> cheers -ben

Re: [Pharo-dev] [Pharo-users] New Iceberg Version 1.2.1

[Tim Mackinnon]

On a slightly related note - and I’m hearing what Norbert is saying as I need 
to work on multi language projects - it would be handy if I could specify the 
name of the project somehow.

My /exercism/pharo repo (which was created for me) - appear in Iceberg as Pharo 
- which is confusing, as I really want to call it Execercism, but have no way 
to do this currently (and I support its something the .projects file would 
enable right?)

Tim

> On 9 Aug 2018, at 11:17, Norbert Hartl  wrote:
> 
> 
> 
>> Am 08.08.2018 um 14:12 schrieb Herbert Vojčík > >:
>> 
>> 
>> 
>> Damien Pollet wrote on 8. 8. 2018 13:53:
>>> First of all, quick stupid question: I'm currently loading my code with 
>>> gitlocal://./src  as the repository URL (my workflow 
>>> starts in a terminal rather than in a Pharo image)
>>> Should I just remove the /src part, now that my repo has the project 
>>> metadata?
>>> Also, are more features planned for the .project file? E.g. what about 
>>> storing a default selection for Calypso and the Test Runner in there?
>>> On Wed, 8 Aug 2018 at 10:28, Norbert Hartl >>  >> >> wrote:
>>>- I don’t think there can be a „standard way“ of defining source
>>>directory. And I don’t think that a tool should enforce this
>>>however. I keep frontend and backend code in some repositories
>>>together so the source is in my case in backend/source. What does it
>>>mean for users not using the „standard“ name?
>>> Sure there can. Look at any ruby or maven project, they all have strong 
>>> conventions for organizing projects and standard config files for deviating 
>>> from those conventions.
>>> I would have preferred if Iceberg picked one convention (arbitrarily) in 
>>> the absence of a .project file instead of forcing its explicit presence. 
>>> IMHO the choice of default directory per se (be it ./, ./src, ./source or 
>>> whatever) matters less than the fact that there is a convention in place.
>>>- I don’t see why there needs to be a 1:1 relationship between a
>>>repository and working copy in pharo. It is like this at the moment
>>>already but the .project file manifests this. So it should not be
>>>supported to have more source dirs in one git repo? It might be not
>>>a good idea that the client has to write the source dir but it opens
>>>the possibility that there can be more than one.
>>> I see your point here, but by using separate source directories you're sort 
>>> of creating a hydra project… What I mean here is that the source 
>>> directories are separate, but their histories are tangled. If you want 
>>> separate source dirs it kinda means that you want separate change 
>>> histories, doesn't it? What if the same class has diverging definitions in 
>>> separate directories (I wonder what maven does in that case…)?
>> 
>> There are monorepos. Some people / companies love them.
>> 
> One of these companies we know for good. It is google. Google has one (!) 
> repositoryf for all their software. 
> 
> And that is the point I want to stretch here. One repo with one project and a 
> standard source directory is too theoretical and too narrow in thoughts. 
> Today there is no possibility to reliably make one product out of multiple 
> repos. Git submodule and git subtree are not even close to something reliable 
> and usable. Descriptions like metacello are language centric. So what is the 
> most secure way of defining a single product? It is the mono repo. That is 
> the main reason I have my sources in backend/source because there is a 
> javascript frontend in the same repo because I want to have one reliable 
> source that defines my product and I can be sure that the backend and 
> frontend are always the ones that match. 
> 
> I don’t think it is a good idea if we once leave the island to embrace 
> something like git just to make git islandish a little later.
> 
> Just to be very clear. We are talking about two files: .project and 
> .properties. I have nothing against .properties because we have multiple 
> formats possible so making it explicit is a good idea. But .project makes 
> every repo a single source repo. If we enforce .properties files why do we 
> not scan the repo for directories containing this file? If none is found we 
> cannot know (or we add looking at some default locations). If multiple 
> directory are found I can add that to iceberg as a real project out of the 
> combination for repository-source directory. This way I could have multiple 
> projects out of one repo. And with the possibility of having multiple source 
> directories it is obvious that the path still needs to be added to a url in 
> metacello. Unless there is one of this directories marked to be the default 
> which would be loaded if no directory is given. This way the default 
> directory would be the one selected if only one is there. So you can have 
> 

Re: [Pharo-dev] [rmod] About the infinite debugger

[Tim Mackinnon]

Thanks Paul - I’d forgotten about that option (been using the close all to 
right option).

It’s just jarring - but worse is that none of the debuggers (even the first 
one) having anything useful in them... other than the error msg in the title. 
So you have to start all over again.

Still, it sounds like we are honing in on something.

Tim

Sent from my iPhone

> On 7 Aug 2018, at 19:38, Paul DeBruicker  wrote:
> 
> Hi Tim,
> 
> Just in the event you didn't know there is an option in the World menu to
> close all the open debuggers. 
> 
> Its in the "Windows" section, about half way down.  
> 
> 
> Paul
> 
> 
> 
> Tim Mackinnon wrote
>> ...
>> 
>> On the plus side - its rare that you crash you image and then have to
>> recover changes - but its just annoying when it gets in the way of
>> debugging. ITs not just all the windows, its also the fact that none of
>> the debugger windows actually puts you in a useful stack where you can see
>> the problem - they are all stuck on DNU with a single line stack.
>> 
>> Tim
>> 
>> ...
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Minheadless trial

[Tim Mackinnon]

Guys - do keep pushing on this - I think its quite important in this world of 
serverless… it shows we are very relevant. +10

> On 7 Aug 2018, at 13:36, Esteban Lorenzano  wrote:
> 
> I’m slowly working on that VM because we want it to be the default for Pharo 
> 8. 
> In our vision, it should be a responsibility of the image to start or not a 
> graphical UI, so we are preparing (we have been preparing to it for years, 
> actually) to achieve this behaviour. 
> To make this work, we need all platforms covered (and another huge quantity 
> of changes here and there). 
> Anyway, I didn’t merge because I wanted to have win64 covered, not just what 
> we have now, and since no-one was using that VM I didn’t feel pression to do 
> it :)
> 
> Cheers, 
> Esteban
> 
> 
>> On 7 Aug 2018, at 08:50, Norbert Hartl > > wrote:
>> 
>> What keeps you from doing a pull request to opensmalltalk-vm ?
>> 
>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano > >:
>> 
>>> Hi Ben,
>>> 
>>> Sorry for coming here so late, I didn’t see this thread before. 
>>> I already have a working minheadless branch that was adapted to Eliot’s 
>>> process. 
>>> It was working for Pharo in Linux and Mac (Windows was ongoing but not 
>>> finished, that’s why is not pushed).
>>> 
>>> You can find this branch here: 
>>> 
>>> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm 
>>> 
>>> 
>>> Interesting part is that I didn’t tackled any of the issues you are working 
>>> on, so the work is easily mergeable :) 
>>> 
>>> Cheers, 
>>> Esteban
>>> 
>>> Ps: with some changes in image, I’m using exclusively this VM since a 
>>> couple of months and it works fine.
>>> 
>>> 
 On 7 Aug 2018, at 07:22, Ben Coman >>> > wrote:
 
 On 7 August 2018 at 05:12, Eliot Miranda >>> > wrote:
  
 Hi Ben, 
 Feel free to make this edit and commit
 
 I'm pushing changes here...
 https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-msvc2017
  
 
 
 and the diff can be tracked here...
 https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
  
 
 
 
 
 On 6 August 2018 at 13:22, Ben Coman >>> > wrote:
 On 6 August 2018 at 11:50, Ben Coman >>> > wrote:
 
 https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/windows/sqPlatformSpecific-Win32.c#L80
  
 
  typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int 
 awareness);
 C2059 sqPlatformSpecific-Win32.c:80 syntax error: '('
 E0651 a calling convention may not be followed by a nested declarator.
 
 The following change reduces build errors to 1...
   typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness);
 
 but I'm not sure of the implications.
 
 I found the correct solution to this...
 "The trick is placing the [call declaration] inside the parentheses"
 https://stackoverflow.com/questions/4830355/function-pointer-and-calling-convention
  
 
 
 i.e. the following compiles cleanly
 typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int 
 awareness); 
 
 
 -
 Now running the VM (without parameters) I get...
Debug Assertion Failed!
Program: ...\x64-Debug\dist\pharo.exe
File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c 
Line: 106
Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0
 
 at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | 
 _MCW_IC);
 https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/windows/sqPlatformSpecific-Win32.c#L118
  
 
 
 
 According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx 
 
 x64 does not support _MCW_PC or _MCW_IC
 but I'm clueless about the implications of these FPU flags.
 Could our math guys please advise?
 
 Eliminating those two flags allows a VM run successfully without loading 
 an 

Re: [Pharo-dev] [rmod] About the infinite debugger

[Tim Mackinnon]

This is a good writeup - however I get infinite debuggers when not running 
tests too? So I’m wondering if there are multiple problems - or if this hints 
at a wider issue?

Its not all of the time - but when you get it it, it seems to happen over and 
over again. Its possible its when using step-over though - so I will keep an 
eye on that.

Tim

> On 7 Aug 2018, at 10:51, teso...@gmail.com wrote:
> 
> Hello, 
>   We have implemented a "patch" for Pharo 7, that is already integrated. I 
> have created a slice to backport the "patch" to Pharo6.
> 
> Basically, the previous situation is the following: 
> 
> - In the normal execution everything works, the problem is during the 
> execution of over. 
> - To implement over the debugger uses Context >> runUntilErrorOrReturnFrom:
> - This method adds a new context to handle exceptions in the stack trace. It 
> takes the receiver and replaces the sender of the context with a new context 
> handling the exceptions.
> - This error handling (using on:do:) handles UnhandledError and Halt. 
> - When the MNU error gots to the nil context a UnhandledError is signal from 
> the last signalling context of the MNU error.
> - This solution works correctly when it is not debugged when running a test.
> 
> When we are running a tests there is a slight difference:
> 
> - There is one more on:do: context that catches all the Errors. This on:do 
> just do something and pass the exception.
> - As the UnhandledError is signal from the last signalling context (the one 
> with the pass) it is not passing in the context inserted by 
> runUntilErrorOrReturnFrom:, generating an infinite debugger as the exception 
> is never catch. 
> - This only happens with the MNU, as it retries to send the same message 
> every time. 
> 
> I think the solution is to signal the UnhandledError always from the original 
> signalling context. However, I am not sure to perform that change as it 
> modifies the behaviour of exceptions and there are not proper tests to 
> guarantee the expected behavior.
> 
> I hope the problem is well explained, if it is not please ask me to clarify 
> any point.
> 
> Cheers,
> 
> On Mon, Aug 6, 2018 at 9:59 AM Guillermo Polito  <mailto:guillermopol...@gmail.com>> wrote:
> Hi Steven,
> 
> The thing about your fix was mainly that it only worked for the case of 
> running tests. We could however reproduce this bug from a playground too.
> 
> At first, replacing #pass to #debug looked like a hack to me :) Just looking 
> at the code of  runCaseForDebug:, I felt the correct thing to do there was to 
> use #pass (and let any potential caller handle the exception if he wants).
> Otherwise, we should be able to understand:
>  - can #pass be used? is it buggy?
>  - does it work on any case or it should be avoided in some cases?
>  - and how can we fix it (or at least document it?)?
> 
> But still, I think you were in the right direction too, because your fix 
> shows a good intuition too: both #pass and #debug will do different things 
> with the exception.
> -  #pass will **resignal** it from the current context,
> -  #debug will just open a debugger on it.
> 
> So that means that probably there was a problem when the exception was 
> handled in a calling context.
> 
> 
> 
> On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou  <mailto:steven.cost...@kloum.io>> wrote:
> Hi,
> 
> i had no answer to my comments on fogbuz (one of the first) so i assumed it 
> was not a good idea.
> 
> In the usecases i used to reproduce the bug, replacing "ex pass" by "ex 
> debug" in runCaseForDebug:solved the problem. See the analysis on fogbuz.
> 
> Did not have any side effect, but i do not know enough about the system and 
> maybe it does. I think i already asked about that somewhere (here or on 
> discord) but no answers.
> 
> But maybe it is wrong to do that? I'd be happy to have feedback on that.
> 
> Steven.
> 
> Le 2018-08-05 22:27, Tim Mackinnon a écrit :
> 
>> Guys - this really needs attention - I've spend hours now trying to debug 
>> some code and most of it is in closing infinite debuggers. It makes a 
>> mockery of our tagline - "awesome debugging". And the extra irony is that 
>> I'm debugging some file path stuff for exercism, to make it easier for 
>> hopefully more people to learn Pharo.
>> 
>> How can we get this fixed?
>> 
>> Tim
>> 
>>> On 2 Aug 2018, at 21:44, Norbert Hartl >> <mailto:norb...@hartl.name>> wrote:
>>> 
>>> bump
>>> 
>>>> Am 04.07.2018 um 02:28 schrieb Martin McClure >>> <mailto:mar...@hand2mouse.com>>:

Re: [Pharo-dev] [rmod] About the infinite debugger

[Tim Mackinnon]

Hey thanks - this is Pharo 6.1, with a zero conf downloaded yesterday, and a 
second image from a week ago. I guess its possible that I don’t have those 
changes - is there an easy way to check? 

I’m happy to try applying them - or use a different image to test with - as it 
seems that certain conditions really rear their head and then you just get the 
problem over and over.

On the plus side - its rare that you crash you image and then have to recover 
changes - but its just annoying when it gets in the way of debugging. ITs not 
just all the windows, its also the fact that none of the debugger windows 
actually puts you in a useful stack where you can see the problem - they are 
all stuck on DNU with a single line stack.

Tim

> On 6 Aug 2018, at 09:46, Guillermo Polito  wrote:
> 
> Hi Tim,
> 
> Are you on Pharo 6 or 7? If in 7, what build are you using?
> 
> Pablo and Santi have made a fix 2 fridays ago (that I presume got integrated 
> last week). The fix consists on changing a bit the exception handling during 
> exception handling.
> 
> https://github.com/pharo-project/pharo/pull/1621/files 
> 
> 
> The fix seems simple, but it has a lot of information contained on it (like 
> the fact that the system introduces exception handlers in the middle of the 
> stack transparently to manage errors while stepping, or the fact that 
> UnhandledError does another traversal of the stack but needs to start at the 
> good place...). The Exception tests we had are still green, and we can now do 
> stepping on code that raises exceptions. When stepping inside the DNU 
> multiple times the debugging experience is not as smooth as the one in Pharo 
> 3 (before it got broken) but this is FAR BETTER than Pharo7 since we have not 
> experienced new infinite debuggers anymore :)...
> 
> I'll let Pablo and Santi answer more properly with the technical details.
> 
> On my side, I think we need to better document and do some more unit tests on 
> that dark part of the system :).
> 
> On Mon, Aug 6, 2018 at 8:50 AM Stéphane Ducasse  > wrote:
> Hi tim
> 
> We know and we made huge progress because before we could not even reproduce 
> it. 
> We spent some times on it. I thought the solution found by pablo and santiago 
> got integrated.
> 
> Stef
> 
>> Guys - this really needs attention - I’ve spend hours now trying to debug 
>> some code and most of it is in closing infinite debuggers. It makes a 
>> mockery of our tagline - “awesome debugging”. And the extra irony is that 
>> I’m debugging some file path stuff for exercism, to make it easier for 
>> hopefully more people to learn Pharo.
>> 
>> How can we get this fixed?
>> 
>> Tim
>> 
>>> On 2 Aug 2018, at 21:44, Norbert Hartl >> > wrote:
>>> 
>>> bump
>>> 
 Am 04.07.2018 um 02:28 schrieb Martin McClure >>> >:
 
> On 07/03/2018 05:02 PM, Martin McClure wrote:
>> On 06/29/2018 07:48 AM, Guillermo Polito wrote:
>> I know that the exception handling/debugging has been modified several
>> times in the latest years (some refactorings, hiding contexts...), we
>> unfortunately don't have tests for it, so I'd like some more pair of
>> eyes on it. Ben, Martin could you take a look?
>> 
> Hi Guille,
> I'm just back from vacation last week, and about to go on vacation for
> another week, but I'll see what I can see.
> About the primitive pragmas for context-marking, I think some of those
> were changed for the exception handling fix that Andres and I did a few
> years back, so *could* be involved in this. I'd hate to see regression
> in the exception handling in an attempt to fix this bug.
> 
 
 After a look at at the pull request, I'm quite sure that removing the
 prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring
 it! The start of execution of exception handlers must be marked in order
 for #findNextHandlerContext to work correctly. If these contexts are not
 marked, exceptions signaled from inside an exception handler can find
 the wrong handler. See the code and comment in #findNextHandlerContext.
 
 I'm afraid that I cannot immediately help with the debugger problem,
 since I don't know the debugger nearly as well as I do the exception
 handling code, and I'm going on vacation for a week in 20 minutes. :-)
 Perhaps when I get back I can take a look at it if it is still a problem
 by then.
 
 Regards,
 -Martin
 
>>> 
>> 
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr 
> http://www.synectique.eu  / http://www.pharo.org 
>  
> 03 59 35 87 52
> Assistant: Julie Jonas 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue 

Re: [Pharo-dev] About the infinite debugger

[Tim Mackinnon]

Guys - this really needs attention - I’ve spend hours now trying to debug some 
code and most of it is in closing infinite debuggers. It makes a mockery of our 
tagline - “awesome debugging”. And the extra irony is that I’m debugging some 
file path stuff for exercism, to make it easier for hopefully more people to 
learn Pharo.

How can we get this fixed?

Tim

> On 2 Aug 2018, at 21:44, Norbert Hartl  wrote:
> 
> bump
> 
>> Am 04.07.2018 um 02:28 schrieb Martin McClure :
>> 
>>> On 07/03/2018 05:02 PM, Martin McClure wrote:
 On 06/29/2018 07:48 AM, Guillermo Polito wrote:
 I know that the exception handling/debugging has been modified several
 times in the latest years (some refactorings, hiding contexts...), we
 unfortunately don't have tests for it, so I'd like some more pair of
 eyes on it. Ben, Martin could you take a look?
 
>>> Hi Guille,
>>> I'm just back from vacation last week, and about to go on vacation for
>>> another week, but I'll see what I can see.
>>> About the primitive pragmas for context-marking, I think some of those
>>> were changed for the exception handling fix that Andres and I did a few
>>> years back, so *could* be involved in this. I'd hate to see regression
>>> in the exception handling in an attempt to fix this bug.
>>> 
>> 
>> After a look at at the pull request, I'm quite sure that removing the
>> prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring
>> it! The start of execution of exception handlers must be marked in order
>> for #findNextHandlerContext to work correctly. If these contexts are not
>> marked, exceptions signaled from inside an exception handler can find
>> the wrong handler. See the code and comment in #findNextHandlerContext.
>> 
>> I'm afraid that I cannot immediately help with the debugger problem,
>> since I don't know the debugger nearly as well as I do the exception
>> handling code, and I'm going on vacation for a week in 20 minutes. :-)
>> Perhaps when I get back I can take a look at it if it is still a problem
>> by then.
>> 
>> Regards,
>> -Martin
>> 
> 

Re: [Pharo-dev] Problem with zinc 2.9.2

[Tim Mackinnon]

Gosh , I’m always impressed how you guys figure this stuff out.

Many thanks to all of you for coming up with a test case and solution(s).

It’s a great community.

Tim

Sent from my iPhone

> On 13 Jul 2018, at 00:19, Nicolas Cellier 
>  wrote:
> 
> Isn't there a recent PR on opensmalltalk that address just this?
> 
>> Le jeu. 12 juil. 2018 à 23:16, Max Leske  a écrit :
>> Hi Norbert,
>> 
>> I was able to reproduce the problem and then identify the culprit, although 
>> what I don't yet understand is how this is related to the changes in Zinc.
>> 
>> Anyway, the problem is that the file stream isn't properly flushed in 
>> ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as the last 
>> statement fixes your problem. Apparently, StandardFileStream / 
>> MultiByteFileStream perform a simple close() on the file which, according to 
>> the man page on close(), does not guarantee that the contents have all been 
>> written to file. In this case a flush is necessary because the entire file 
>> is immediately read again.
>> 
>> Here's a smaller test case for you to play with Sven:
>> 
>> ZnClient new
>> url: 'https://github.com/zweidenker/Parasol/archive/master.zip';
>> downloadTo: '/tmp/foobar.zip'.
>> bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s 
>> contents ].
>> Transcript open; show: bytes size; cr.
>> 5 seconds asDelay wait.
>> Transcript show: ('/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s 
>> | s contents ]) size.
>> The output in the Transcript should be:
>> 
>> 315392
>> 318420
>> Cheers,
>> Max
>> 
>> On 12 Jul 2018, at 8:17, Norbert Hartl wrote:
>> 
>> Am 12.07.2018 um 08:05 schrieb Max Leske maxle...@gmail.com:
>> 
>> On 11 Jul 2018, at 22:44, Norbert Hartl wrote:
>> 
>> Hi Max,
>> 
>> I constructed a case that fails exactly like I experience it. Could you try? 
>> Just unpack the attachment on a linux, set PHARO_VM env to your executable 
>> and execute build.sh
>> 
>> I will. Might take a couple of days though.
>> 
>> No problem. I‘m happy if you find time.
>> 
>> Norbert
>> 
>> Max
>> 
>> Norbert
>> 
>> Am 10.07.2018 um 09:17 schrieb Max Leske maxle...@gmail.com:
>> 
>> On 10 Jul 2018, at 8:48, Norbert Hartl wrote:
>> 
>> Max,
>> 
>> thanks for taking the effort.
>> 
>> No worries.
>> 
>> Am 10.07.2018 um 08:37 schrieb Max Leske maxle...@gmail.com:
>> 
>> I did my best to reproduce the issue but didn't have any luck. I really need 
>> access to a Linux VM to debug this. So I'm praying that Apple fixes the 
>> access restrictions to kernel extensions in their next beta...
>> 
>> BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there is 
>> indeed a chance that something goes wrong during download of the zip archive 
>> and that something may be tied to a difference in the versions of Zinc 
>> (although I still think that's unlikely).
>> 
>> Yes there is potential but I don‘t see it. I take a fresh 6.1 image and load 
>> my project into. I‘m not sure but I think zinc 2.9.2 is loaded rather early 
>> in that process. So I wonder why it does not go wrong in the first phase. 
>> And also not if I load the test group within the first phase.
>> It must be either the second Metacello invocation or the stopping, copying 
>> and starting of the image.
>> I try to isolate this case more and provide a script that goes wrong on my 
>> machine. But it will take some time because I needed to stop trying to solve 
>> this as I wasted nearly two days on that already.
>> 
>> Let me know once you have something and I'll try to help out.
>> 
>> Norbert
>> 
>> Max
>> 
>> On 9 Jul 2018, at 19:43, Norbert Hartl wrote:
>> 
>> Am 09.07.2018 um 19:10 schrieb Max Leske maxle...@gmail.com:
>> 
>> I checked the Parasol Archive and it does not appear to be in Zip64 format 
>> (Metacello uses ZipArchive which can't cope with Zip64 but ZipArchive can 
>> read the Parasol zip). So my next guess is that there's either a problem 
>> with Metacello or Pharo in the way that ZipArchive is used (e.g. endianness 
>> problem or non-binary stream data). It would therefore be helpful to find 
>> out what happens in ZipArchive>>readFrom:, i.e. what kind of stream is 
>> passed / opened, is it binary, does the file exist and is it still the 
>> correct file.
>> 
>> I couldn’t see anything obvious. The file in the debug message exists, it is 
>> a readable zip file. The way Metacello uses it it is a StandardFileStream. 
>> It switches it to binary in the code.
>> But the only difference between a working and non-working build is the 
>> upgrade to zinc 2.9.2.
>> 
>> Norbert
>> 
>> I'd debug it myself but I can't run VirtualBox at the moment because I'm on 
>> the macOS beta and it won't start...
>> 
>> Max
>> 
>> On 9 Jul 2018, at 18:31, Norbert Hartl wrote:
>> 
>> Hi Max,
>> 
>> Am 09.07.2018 um 18:18 schrieb Max Leske maxle...@gmail.com:
>> 
>> Hi Norbert,
>> 
>> This is a bit of a guess, but it's possible that the archive that is 
>> downloaded from github is in 

Re: [Pharo-dev] [Pharo-users] Which command-line handlers do you use most?

[Tim Mackinnon]

Does the metacello cmd line option work for git based projects? I could never 
work it out and always reverted to a script, but would be handy if it does work.

Tim

Sent from my iPhone

> On 10 Jul 2018, at 16:24, Damien Pollet  wrote:
> 
>> On Mon, 9 Jul 2018 at 18:48, Sven Van Caekenberghe  wrote:
>> Most used: eval, config, st (default to run script.st)
> 
> Do you ever use the metacello one instead of config?
>  
>> Please make sure to stay as compatible as possible, lots of CI and server 
>> deploy/run code depends on it.
> 
> 
> I intend to provide similar features and a path for migrating with minimal 
> headaches, but there are several idiosyncrasies that I hope to get rid of as 
> well.
> I guess the big users of deploy/run code will come see me at ESUG and we can 
> see what's best ;-)
> 
> -- 
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] Commenting test classes?

[Tim Mackinnon]

Au contraire - when looking at a Test - seeing inline the comment of the class 
to remind me what I’m supposed to be testing is actually quite helpful. I fully 
expect this is where GtDocumentor is going to take us (if we integrate it into 
our tools) - letting us inline things so we don’t have to go and hunt them out.

> On 3 Jul 2018, at 22:32, Norbert Hartl  wrote:
> 
> 
> 
> Am 03.07.2018 um 22:40 schrieb Tim Mackinnon  <mailto:tim@testit.works>>:
> 
>> And/Or we could display some automatic comment text (unless some is 
>> provided).
>> 
>> Somethings like 
>> 
>> Tests for Xxx
>> 
>> (Xxx comment eg I am class that provides services)
>> 
> Another example of counter productivity!
> 
> Norbert
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On 3 Jul 2018, at 20:21, Gabriel Cotelli > <mailto:g.cote...@gmail.com>> wrote:
>> 
>>> Hi,
>>> I think that for TestCase subclasses 90% of the time the comment end up in 
>>> "Unit test of blablabl". Maybe a really complex test case justifies a 
>>> comment, but it's not the common case. 
>>> If we can disable the missing comment feedback on TestCase subclasses I 
>>> will certainly disable it.
>>> 
>>> On Tue, Jul 3, 2018 at 3:48 PM Denis Kudriashov >> <mailto:dionisi...@gmail.com>> wrote:
>>> Hi.
>>> 
>>> I noticed pull requests which add comments to test cases (class comments).
>>> I guess the reason is that in Calypso uncommented classes are marked 
>>> differently than in Nautilus and the exclamation does not disappear when 
>>> class provides special icon like status of tests.
>>> 
>>> So the question is do we really want people comment test cases?
>>> I did not notice any meaningful comment from those PRs. It's like "Unit 
>>> tests for mirror primitives" for MirrorPrimitiveTests (case 22207 
>>> <https://github.com/pharo-project/pharo/pull/1598>).
>>> Personally I don't like such approach to put class name with spaces in the 
>>> comment. It is useless and duplicated.
>>> 
>>> Alternatively I can change uncommented mark to be like in Nautilus. 
>>> But I like Calypso approach because #systemIcon is not overridden by 
>>> exclamation. If we want to keep it we need to introduce some 
>>> #requiresComment to Class which will be overridden by TestCase.
>>> 
>>> So what you think?
>>> 
>>>  
>>> 
>>> 

Re: [Pharo-dev] Commenting test classes?

[Tim Mackinnon]

And/Or we could display some automatic comment text (unless some is provided).

Somethings like 

Tests for Xxx

(Xxx comment eg I am class that provides services)





Sent from my iPhone

> On 3 Jul 2018, at 20:21, Gabriel Cotelli  wrote:
> 
> Hi,
> I think that for TestCase subclasses 90% of the time the comment end up in 
> "Unit test of blablabl". Maybe a really complex test case justifies a 
> comment, but it's not the common case. 
> If we can disable the missing comment feedback on TestCase subclasses I will 
> certainly disable it.
> 
>> On Tue, Jul 3, 2018 at 3:48 PM Denis Kudriashov  wrote:
>> Hi.
>> 
>> I noticed pull requests which add comments to test cases (class comments).
>> I guess the reason is that in Calypso uncommented classes are marked 
>> differently than in Nautilus and the exclamation does not disappear when 
>> class provides special icon like status of tests.
>> 
>> So the question is do we really want people comment test cases?
>> I did not notice any meaningful comment from those PRs. It's like "Unit 
>> tests for mirror primitives" for MirrorPrimitiveTests (case 22207).
>> Personally I don't like such approach to put class name with spaces in the 
>> comment. It is useless and duplicated.
>> 
>> Alternatively I can change uncommented mark to be like in Nautilus. 
>> But I like Calypso approach because #systemIcon is not overridden by 
>> exclamation. If we want to keep it we need to introduce some 
>> #requiresComment to Class which will be overridden by TestCase.
>> 
>> So what you think?
>> 
>>  
>> 
>> 

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

[Tim Mackinnon]

Actually - it looks like a caching thing - as in a clean image, if I use my 
reduced baseline (without the Tests) it loads (albeit with a deprecation 
warning).

Does anyone know what you have to clear to get it to honour the baseline code 
you actually have in your image - as its a faff to have to use a clean image?

(This is a constant frustration in Smalltalk - caches are useful and all, but 
there isn’t a consistent way to reset frameworks - I really long for a pragma 
for reset, and a menu item somewhere that shows you a reset menu for all the 
frameworks you have loaded, so its easy to clear things and get to a consistent 
state…)

Tim

> On 21 Jun 2018, at 14:58, Tim Mackinnon  wrote:
> 
> Hi guys - how did you load Seaside into Pharo 7 as part of a baseline? I’ve 
> hit a similar same problem and am getting a walkback error when trying to 
> load a baseline for a project I wanted to try on P7 which uses seaside.
> 
> I get: MetacelloNameNotDefinedError: project group, or package named: 
> 'Seaside-Pharo-Development' not found when used in requires: or includes: 
> field of package: 'Seaside-Tests-Pharo-Development' for version: baseline of 
> BaselineOfSeaside3.
> 
> My baseline has the following:
> 
> setUpDependencies: spec
> 
>   spec
>   baseline: 'Seaside3'
>   with: [ spec
>   repository: 
> 'github://SeasideSt/Seaside:master/repository';
>   loads: #('Seaside-Environment') ].
> 
> 
> If did have (copied from a Willow example) - and I’m wondering if something 
> is getting cached and that its not actually using the above - but I’m not 
> clear on how to ensure any caches are cleared?
> 
> spec
>   baseline: 'Seaside3'
>   with: [ spec
>   repository: 
> 'github://SeasideSt/Seaside:v3.2.4/repository';
>   loads: #('Seaside-Environment' 'JQuery' 'Zinc') 
> ];
>   project: 'Seaside3-Tests' copyFrom: 'Seaside3' with: [ spec 
> loads: #('Seaside-Tests-Core') ].
> 
> Any tips gratefully received.
> 
> Tim
> 
>> On 24 May 2018, at 16:02, Sven Van Caekenberghe  wrote:
>> 
>> Hi Torsten,
>> 
>> Thanks for taking care.
>> 
>> I can confirm, from a quick test, that Seaside loads/works fine in the 
>> latest Pharo 7.
>> 
>> I had trouble opening the Seaside Control Panel, 10s of deprecation warnings 
>> opening for the icon base64 decoding, I had to comment out the #deprecated: 
>> message send in #mimeDecodeToBytes:
>> 
>> I don't understand why the Grease stream tests are failing since they seem 
>> to be testing ReadWriteStream, a class that was not changed, at all.
>> 
>> Sven 
>> 
>>> On 22 May 2018, at 22:01, Torsten Bergmann  wrote:
>>> 
>>> Just as an info: after fixing the #mimeDecodeToBytes: issue with recent 
>>> image 70934 and later it is possible
>>> to load Seaside again from GitHub using 
>>> 
>>> Metacello new
>>> baseline:'Seaside3';
>>> repository: 'github://SeasideSt/Seaside:master/repository';
>>> load
>>> 
>>> 
>>> into a recent Pharo 7.0 (load instruction as recommended on 
>>> https://github.com/SeasideSt/Seaside).
>>> 
>>> For the deprecated warnings you either "Proceed" or disable them for the 
>>> time being.
>>> 
>>> 799 of 806 Seaside tests passes 
>>> 470 of 457 Grease  tests passes
>>> 
>>> primarily failing to to non-compatible streams. Seaside and Grease tests 
>>> seem to test
>>> some ANSI related things - who fail now.
>>> 
>>> ___
>>> seaside-dev mailing list
>>> seaside-...@lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>> 
>> 
> 
> 

Re: [Pharo-dev] Debugger Button Positioning

[Tim Mackinnon]

> The whole point about pragmas is that they're supposed to be messages, and 
> hence senders (and if possible, implementors) work.  But with the mangling 
> that occurs here, a simple senders of stackDebuggingActions brings nothing, 
> and one is left manually searching the system before one finds references to 
> gtStackDebuggingAction.  Obscure and hence horrible.

Hi Eliot - I’ve been caught out by that belief too - but if you select a pragma 
and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think 
you are expecting and shows you all the senders of that pragma. I use this all 
of the time for remember how to implement GT-Inspector tabs , as I was always 
impressed with the one in Date and use it as a way to find lots of good 
examples.

It could be, that you tried “implementers of” - and that one always confuses me 
- partly because they aren’t a real thing (and I guess I agree with you on a 
distaste for them - it feels like we could have done better somehow?).

Tim


> On 15 Jun 2018, at 00:23, Eliot Miranda  wrote:
> 
> Hi Henrik,
> 
> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard  > wrote:
> Hi,
> 
> Moving the icons down to the middle row is as simple as changing:
> 
> ***
> codeActionsPragmas 
>   ^ #( stackDebuggingActions codeDebuggingActions )
> ***
> ***
> stackDebuggingActionsPragmas
>   ^ #()
> ***
> 
> in GTGenericStackDebugger.
> 
> Best regards,
> Henrik
> 
> Thanks.  I have to say that the renaming from #stackDebuggingActions to 
> gtStackDebuggingAction, as in
> 
> StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger
>
> 
> is a cruel joke.  The whole point about pragmas is that they're supposed to 
> be messages, and hence senders (and if possible, implementors) work.  But 
> with the mangling that occurs here, a simple senders of stackDebuggingActions 
> brings nothing, and one is left manually searching the system before one 
> finds references to gtStackDebuggingAction.  Obscure and hence horrible.
> 
> _,,,^..^,,,_
> best, Eliot "I designed pragmas to be useful and natural, not painful and 
> obscure" Miranda

Re: [Pharo-dev] Recent Pharo does not work (to me) with "El Capitan"

[Tim Mackinnon]

I think you can run the latest Pharo but with a slighter older vm with no issue 
(not sure - but think I’ve heard folks say this)

Tim

Sent from my iPhone

> On 14 Jun 2018, at 09:58, Jordi Delgado  wrote:
> 
> I think that is a great idea. El Capitan is not that old and I bet there are 
> a lot of computers still running it.
> 
> In my case, an iMac bought in 2007 with 4Gb ram, 512 Gb SSD disk and El 
> Capitan works like a charm, and I'm not going to quit using it until it stops 
> working. It's a pity that I cannot run the latest Pharo in it (I have no 
> problem with the latest versions of any of the other software I regularly 
> use).
> 
> What you suggest is quite reasonable. Offering a Pharo 6.1 for OS X 
> pre-Sierra (as far as you can go backwards in time) would be great. Provided 
> it is possible, of course (maybe 6.1 images do not run in previous vm's; I do 
> not know).
> 
>> On 14/06/18 10:44, Tim Mackinnon wrote:
>> I guess we should work out which vm still works and put that as a footnote 
>> on the installation page? Possibly not worth fixing it for something several 
>> os versions black?
>> Tim
>> Sent from my iPhone
>>> On 14 Jun 2018, at 09:37, Jordi Delgado  wrote:
>>> 
>>> Hi,
>>> 
>>> I checked with Sierra and High Sierra, both Pharo and Squeak and everything 
>>> works ok.
>>> 
>>> Thus, I guess some change/improvement was done to the vm's that broke them 
>>> for El Capitan.
>>> 
>>> Thanks for your answers.
>>> 
>>> On 13/06/18 23:41, Esteban Lorenzano wrote:
>>>>> On 13 Jun 2018, at 22:57, Jordi Delgado  wrote:
>>>>> 
>>>>> Yes, I did. Same result.
>>>>> 
>>>>> All the same happens with the latest version of Squeak.
>>>>> 
>>>>> I tried with High Sierra. In HS Pharo 6.1 starts, the image opens but
>>>>> then it complains about not being able to create some file in
>>>>> /Private/var/... and the image becomes unusable. In High Sierra the
>>>>> latest version of Squeak opens correctly.
>>>> this is because you are trying to execute a non-signed VM then it puts you 
>>>> in a sandbox.
>>>> easy fix: copy your VM into Applications and execute from there.
>>>>> 
>>>>> Tomorrow I will try with Sierra, on a clean computer (a computer that
>>>>> never had a Smalltalk installed in it).
>>>>> 
>>>>> I insist. You do not find any of these problems with Ubuntu. Quoting
>>>>> Robert de Niro, f*ck Apple ;)
>>>> well, but is very weird.
>>>> most of use work on mac and we do not have this problems (yes the one 
>>>> about the signed VM, but just that one).
>>>> Esteban
>>>>> 
>>>>> El 13/6/18 a les 21:55, Tim Mackinnon ha escrit:
>>>>>> Have you tried the 32bit version - just to rule that out? You did the 
>>>>>> 64bit version - not sure how El Capitan faired with that?
>>>>>> 
>>>>>> 
>>>>> 
>>>>> -- 
>>>>> Salut!
>>>>> 
>>>>> Jordi Delgado
>>>>> 
>>>>> Computer Science Department - Universitat Politècnica de Catalunya
>>>>> Campus Nord, Omega building,
>>>>> Office S115 c/Jordi Girona Salgado, 1-3
>>>>> 08034 Barcelona, Spain.
>>>>> Phone: +34.93.413.40.18
>>>>> Public Key: 
>>>>> https://pgp.mit.edu/pks/lookup?op=get=0xB7911543AD9E79A8
>>>>> 
>>> 
>>> -- 
>>> Salut!
>>> 
>>> Jordi Delgado
>>> 
>>> Computer Science Department - Universitat Politècnica de Catalunya
>>> Campus Nord, Omega building,
>>> Office S115 c/Jordi Girona Salgado, 1-3
>>> 08034 Barcelona, Spain.
>>> Phone: +34.93.413.40.18
>>> Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xB7911543AD9E79A8
>>> 
> 
> -- 
> Salut!
> 
> Jordi Delgado
> 
> Computer Science Department - Universitat Politècnica de Catalunya
> Campus Nord, Omega building,
> Office S115 c/Jordi Girona Salgado, 1-3
> 08034 Barcelona, Spain.
> Phone: +34.93.413.40.18
> Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xB7911543AD9E79A8
> 

Re: [Pharo-dev] Recent Pharo does not work (to me) with "El Capitan"

[Tim Mackinnon]

I guess we should work out which vm still works and put that as a footnote on 
the installation page? Possibly not worth fixing it for something several os 
versions black?

Tim

Sent from my iPhone

> On 14 Jun 2018, at 09:37, Jordi Delgado  wrote:
> 
> Hi,
> 
> I checked with Sierra and High Sierra, both Pharo and Squeak and everything 
> works ok.
> 
> Thus, I guess some change/improvement was done to the vm's that broke them 
> for El Capitan.
> 
> Thanks for your answers.
> 
> On 13/06/18 23:41, Esteban Lorenzano wrote:
>>> On 13 Jun 2018, at 22:57, Jordi Delgado  wrote:
>>> 
>>> Yes, I did. Same result.
>>> 
>>> All the same happens with the latest version of Squeak.
>>> 
>>> I tried with High Sierra. In HS Pharo 6.1 starts, the image opens but
>>> then it complains about not being able to create some file in
>>> /Private/var/... and the image becomes unusable. In High Sierra the
>>> latest version of Squeak opens correctly.
>> this is because you are trying to execute a non-signed VM then it puts you 
>> in a sandbox.
>> easy fix: copy your VM into Applications and execute from there.
>>> 
>>> Tomorrow I will try with Sierra, on a clean computer (a computer that
>>> never had a Smalltalk installed in it).
>>> 
>>> I insist. You do not find any of these problems with Ubuntu. Quoting
>>> Robert de Niro, f*ck Apple ;)
>> well, but is very weird.
>> most of use work on mac and we do not have this problems (yes the one about 
>> the signed VM, but just that one).
>> Esteban
>>> 
>>> El 13/6/18 a les 21:55, Tim Mackinnon ha escrit:
>>>> Have you tried the 32bit version - just to rule that out? You did the 
>>>> 64bit version - not sure how El Capitan faired with that?
>>>> 
>>>> 
>>> 
>>> -- 
>>> Salut!
>>> 
>>> Jordi Delgado
>>> 
>>> Computer Science Department - Universitat Politècnica de Catalunya
>>> Campus Nord, Omega building,
>>> Office S115 c/Jordi Girona Salgado, 1-3
>>> 08034 Barcelona, Spain.
>>> Phone: +34.93.413.40.18
>>> Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xB7911543AD9E79A8
>>> 
> 
> -- 
> Salut!
> 
> Jordi Delgado
> 
> Computer Science Department - Universitat Politècnica de Catalunya
> Campus Nord, Omega building,
> Office S115 c/Jordi Girona Salgado, 1-3
> 08034 Barcelona, Spain.
> Phone: +34.93.413.40.18
> Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xB7911543AD9E79A8
> 

Re: [Pharo-dev] Sista & Pharo 7

[Tim Mackinnon]

Sad - but a wise decision, there was a already a lot going on.

Tim

Sent from my iPhone



Sent from my iPhone
> On 14 Jun 2018, at 07:42, Esteban Lorenzano  wrote:
> 
> yes, Sista will not be in P7 sadly. 
> we postponed almost all VM relative stuff because of complications to get it 
> ready

Re: [Pharo-dev] Recent Pharo does not work (to me) with "El Capitan"

[Tim Mackinnon]

Have you tried the 32bit version - just to rule that out? You did the 64bit 
version - not sure how El Capitan faired with that?


Tim

> On 13 Jun 2018, at 20:11, Jordi Delgado  wrote:
> 
> Thanks for your answer Tim.
> 
> That's one of the multiple things I've tried. I did it again and here
> you have the complete session, starting from an empty directory:
> 
> 
> iMac-de-Jordi-2:tmp jordi$ ls -al
> total 0
> drwxr-xr-x   2 jordi  staff68 13 jun 21:01 .
> drwxr-x---@ 49 jordi  staff  1666 13 jun 19:45 ..
> 
> 
> iMac-de-Jordi-2:tmp jordi$ curl https://get.pharo.org/64/ | bash
>  % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
> Dload  Upload   Total   SpentLeft
> Speed
> 100 11324  100 113240 0  26168  0 --:--:-- --:--:-- --:--:--
> 26152
> Downloading the latest 61 Image:
>http://files.pharo.org/get-files/61/pharo64.zip
> Pharo.image
> Downloading the latest pharoVM:
>   http://files.pharo.org/get-files/61/pharo64-mac-stable.zip
> pharo-vm/Pharo.app/Contents/MacOS/Pharo
> Downloading PharoV61.sources:
>   http://files.pharo.org/get-files/61/sources.zip
> Creating starter scripts pharo and pharo-ui
> 
> 
> iMac-de-Jordi-2:tmp jordi$ ls -la
> total 112456
> drwxr-xr-x   8 jordi  staff   272 13 jun 21:02 .
> drwxr-x---@ 49 jordi  staff  1666 13 jun 19:45 ..
> -rw-rw-r--   1 jordi  staff   7694724  5 abr 14:36 Pharo.changes
> -rw-rw-r--   1 jordi  staff  49867880  5 abr 14:36 Pharo.image
> -rwxr-xr-x   1 jordi  staff   390 13 jun 21:01 pharo
> -rwxr-xr-x   1 jordi  staff   379 13 jun 21:01 pharo-ui
> drwxr-xr-x   5 jordi  staff   170 13 jun 21:01 pharo-vm
> 
> 
> iMac-de-Jordi-2:tmp jordi$ ./pharo Pharo.image --help
> 
> Illegal instruction Wed Jun 13 21:02:06 2018
> 
> 
> VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Date: Wed May 9 10:36:12 2018 CommitHash: 334be97
> Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> 
> ./pharo: line 11:  3483 Abort trap: 6
> "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@"
> 
> 
> 
> And that's it :(
> 
> El 13/6/18 a les 20:52, Tim Mackinnon ha escrit:
>> 
>> Hmm - it’s an older MacOS but I recall it working back then. The msg about 
>> —headless looks a bit suspicious. Are you running what you think you are 
>> running?
>> 
>> Try following the command line instructions for a zero conf install in a 
>> terminal in a fresh directory, that might give you better feedback (and may 
>> just work).
>> 
>> Tim
>> 
>> Sent from my iPhone
>> 
> 
> -- 
> Salut!
> 
> Jordi Delgado
> 
> Computer Science Department - Universitat Politècnica de Catalunya
> Campus Nord, Omega building,
> Office S115 c/Jordi Girona Salgado, 1-3
> 08034 Barcelona, Spain.
> Phone: +34.93.413.40.18
> Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xB7911543AD9E79A8
> 

Re: [Pharo-dev] Recent Pharo does not work (to me) with "El Capitan"

[Tim Mackinnon]

Just to be clear - the instructions on pharo.org/download where it says:
curl https://get.pharo.org | bash
And then run it via

./pharo-ui Pharo.image

> On 13 Jun 2018, at 19:52, Tim Mackinnon  wrote:
> 
> 
> Hmm - it’s an older MacOS but I recall it working back then. The msg about 
> —headless looks a bit suspicious. Are you running what you think you are 
> running?
> 
> Try following the command line instructions for a zero conf install in a 
> terminal in a fresh directory, that might give you better feedback (and may 
> just work).
> 
> Tim
> 
> Sent from my iPhone
> 
>> On 13 Jun 2018, at 19:07, Jordi Delgado  wrote:
>> 
>> Hi,
>> 
>> First of all, thanks everybody for your effort making Pharo. It's hugely
>> appreciated.
>> 
>> But..., I cannot make Pharo 6 or 7 work in os x "El Capitan". I've tried
>> stable and latest for images and vm's, either 6.0, 6.1 and 7.0. Any
>> combination fails to start. Also, no download from Pharo.org works for
>> me (not the launcher, not the standalone).
>> 
>> It's always an error that looks like this one:
>> 
>> "Illegal instruction Wed Jun 13 19:52:37 2018
>> 
>> 
>> VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> Date: Wed May 9 10:36:12 2018 CommitHash: 334be97
>> Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> 
>> ./pharo: line 11:  2623 Abort trap: 6
>> "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@""
>> 
>> Is this a known problem (hopefully with some known workaround), or is it
>> me getting old? I am not new to Pharo and everything worked fine up to
>> Pharo 5.0.
>> 
>> This problem only appears in os x "El Capitan". I use Pharo, any
>> version, in Ubuntu with no problem at all.
>> 
>> Thanks in advance,
>> 
>> -- 
>> Bests,
>> 
>> Jordi Delgado
>> 
>> Computer Science Department - Universitat Politècnica de Catalunya
>> Campus Nord, Omega building,
>> Office S115 c/Jordi Girona Salgado, 1-3
>> 08034 Barcelona, Spain.
>> Phone: +34.93.413.40.18
>> Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xB7911543AD9E79A8
>> 
> 
> 

Re: [Pharo-dev] Recent Pharo does not work (to me) with "El Capitan"

[Tim Mackinnon]

Hmm - it’s an older MacOS but I recall it working back then. The msg about 
—headless looks a bit suspicious. Are you running what you think you are 
running?

Try following the command line instructions for a zero conf install in a 
terminal in a fresh directory, that might give you better feedback (and may 
just work).

Tim

Sent from my iPhone

> On 13 Jun 2018, at 19:07, Jordi Delgado  wrote:
> 
> Hi,
> 
> First of all, thanks everybody for your effort making Pharo. It's hugely
> appreciated.
> 
> But..., I cannot make Pharo 6 or 7 work in os x "El Capitan". I've tried
> stable and latest for images and vm's, either 6.0, 6.1 and 7.0. Any
> combination fails to start. Also, no download from Pharo.org works for
> me (not the launcher, not the standalone).
> 
> It's always an error that looks like this one:
> 
> "Illegal instruction Wed Jun 13 19:52:37 2018
> 
> 
> VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Date: Wed May 9 10:36:12 2018 CommitHash: 334be97
> Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> 
> ./pharo: line 11:  2623 Abort trap: 6
> "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@""
> 
> Is this a known problem (hopefully with some known workaround), or is it
> me getting old? I am not new to Pharo and everything worked fine up to
> Pharo 5.0.
> 
> This problem only appears in os x "El Capitan". I use Pharo, any
> version, in Ubuntu with no problem at all.
> 
> Thanks in advance,
> 
> -- 
> Bests,
> 
> Jordi Delgado
> 
> Computer Science Department - Universitat Politècnica de Catalunya
> Campus Nord, Omega building,
> Office S115 c/Jordi Girona Salgado, 1-3
> 08034 Barcelona, Spain.
> Phone: +34.93.413.40.18
> Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xB7911543AD9E79A8
> 

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

[Tim Mackinnon]

I have installed it fine now - I think the message is less ambiguous if the 
latest Pharo, is called the “latest Pharo 7” - thats where my confusion was.

Is it worth reporting any bugs with this version in 6.1? I got an error dialog 
that was telling me about the project I was trying to load already existing on 
my disk - however the window is too small and so you don’t see that there is a 
Debug/Ignore button way off to the right (you have to stretch the dialog to see 
them).

I also wonder if we are trying to be too clever with how you specify a 
Gitlab/Github project - both those sites have a little button you click to copy 
the full url of the project you want to clone - we are now asking people to not 
use that, but instead to copy the name of the project (which is typically the 
title Text above that url and copy button). This is very different from how 
every tool I use works and is a bit confusing.

Tim

> On 13 Jun 2018, at 12:13, Cyril Ferlicot D.  wrote:
> 
> On 13/06/2018 12:57, Tim Mackinnon wrote:
>> Hi I’m a bit confused by what is described below - when it says "This is
>> already in latest Pharo build. If you want to try it in a Pharo 6.1 ….”
>> - does that mean its already in the latest Pharo 7 (emphasis on 7?)
>> build (and I can see it in Pharo 7) - but the latest 6.1 build doesn’t
>> have it and you must follow the steps you described?
>> 
> 
> Hi!
> 
> Each time an Iceberg stable version is released, it is integrated to
> Pharo 7. (Usually, it's available the next day the time to do the PR,
> test it, integrate it and build the new version)
> 
> Pharo 6.1 is still at the v0.6 of Iceberg. IIUC, thi is mostly because
> the new UI depends on a lot of changes from Pharo 7 and backporting it
> would mean backport too many changes. The goal is to keep Pharo 6.1 as
> stable as possible.
> 
> So the steps to update yourself Iceberg to v1.? is for Pharo 6 only.
> 
>> I initially read it to mean that new Pharo 6.1 builds would
>> automatically get it - but that doesn’t seem to be the case?
>> 
>> Tim
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

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

[Tim Mackinnon]

Hi I’m a bit confused by what is described below - when it says "This is 
already in latest Pharo build. If you want to try it in a Pharo 6.1 ….” - does 
that mean its already in the latest Pharo 7 (emphasis on 7?) build (and I can 
see it in Pharo 7) - but the latest 6.1 build doesn’t have it and you must 
follow the steps you described?

I initially read it to mean that new Pharo 6.1 builds would automatically get 
it - but that doesn’t seem to be the case?

Tim

> On 11 Jun 2018, at 22:04, Guillermo Polito  wrote:
> 
> 
> 
> On Mon, Jun 11, 2018 at 7:23 PM, Hernán Morales Durand 
> mailto:hernan.mora...@gmail.com>> wrote:
> Hi Guille,
> 
> Thank you for the update.
> Can this be installed in Pharo 6.1? How?
> 
> This is already in latest Pharo build. If you want to try it in a Pharo 6.1 
> (I recommend to do it in a clean image), you can follow the instructions in 
> the README





> 
> https://github.com/pharo-vcs/iceberg#for-pharo-61 
> 
> 
> Those instructions will unload iceberg and install the latest 1.* version
>  
> It was tested on Windows?
> 
> I did not do it personally, but I know Cyril is using it in windows 
> successfully for a couple of months already.
> He's even using it to contribute to Pharo and Iceberg itself from windows.
> 
> I'd like to have the tests running on windows, but for that we need 
> OSSubprocess running on windows... (Or maybe depending on ProcessWrapper is a 
> compromise solution?). If someone would like to help on that front, making 
> use of ProcessWrapper in the tests should not be difficult (it was done 
> before but that code rot because of the lack of CI in the past...)
>  
> 
> Cheers,
> 
> Hernán
> 
> 
> 2018-06-11 14:04 GMT-03:00 Guillermo Polito  >:
> > Time for the weekly Iceberg update.
> > Thanks to all brave users, issue reporters and contributors :).
> >
> > Key changes: we have introduced some tag support, a new credential manager
> > to manage keys and passwords per host or repository, a new version of tonel,
> > and made a first step towards a simplified contribution to Iceberg by
> > listing it as Pharo's repository.
> >
> > Enjoy,
> > Guille in behalf of all Iceberg contributors
> >
> > Following, the detailed changes log.
> >
> > New Features
> > #842 Adding Credentials Store
> > #843 Update Tonel to 1.0.7
> > #823 Iceberg repository should be listed as Pharo's one
> > #841 Basic tag support (#372)
> >
> > Infrastructure
> > #787 Add Windows ci with Appveyor (not yet green!)
> >
> > Enhancements
> > #827 Add package dialog has some glitches
> > #833 replace #asIcon with #iconNamed:
> > #832 Move Iceberg from MostUsedTools to Tools
> > #830 Better handling of not github remote urls
> > #825 Enhance Migrate to tonel commit message
> > #637 Show tag version instead of "Detached HEAD"
> > #829 migrate-versions-browser
> >
> > Bug Fixes
> > #835 Compare file definitions by their binary uninterpreted content
> > #838 Clone from incorrect github repository fails with DNU
> > #826 Pushing to virgin repository raises a DNU
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13

Re: [Pharo-dev] Pharo 7 on SqueakJS (demo)

[Tim Mackinnon]

Interestingly - its faster on my iPhoneX than on my 2015 MacBook Pro - shows 
how much the processor speeds are advancing.



> On 24 May 2018, at 16:51, Esteban A. Maringolo  wrote:
> 
> Nice experiment!
> The fact that it works it's a feat itself.
> 
> Maybe in the future with WebAssembly and a lighter/core image it will
> became a viable alternative.
> 
> 
> 
> On 21/05/2018 07:01, Pavel Krivanek wrote:
>> Hi,
>> 
>> with some tweaks mostly related to FFI and fonts, we are able to run
>> Pharo 7 on SqueakJS VM.
>> 
>> Do not expect blazing performance. Currently, it is about two orders of
>> magnitude slower than the native VM. 
>> 
>> https://pavel-krivanek.github.io/pharo/pharo.html
>> 
>> Cheers,
>> -- Pavel
> 
> -- 
> Esteban A. Maringolo
> 

Re: [Pharo-dev] IMPORTANT: ML Etiquette

[Tim Mackinnon]

Sent from my iPhone
> On 28 May 2018, at 17:26, Stephan Eggermont  wrote:
> 
> 
>> Sent from my iPhone
> 
> That supports NewsTap, which makes it easy to not top-post. I’m not sure
> why lines are not broken though. 

I’ll try my best - but the normal iPhone mail client simply doesn’t work this 
way - it top posts. I think we’re on a losing battle with this one.

I do have a copy of NewsTap - I’ll try it again, but I recall mail is just more 
convenient.

I think Stef is possibly right - if we’re arguing about top vs bottom - we’re 
better off writing code instead - it possibly means a thread has gone in too 
long.

Tim

Re: [Pharo-dev] IMPORTANT: ML Etiquette

[Tim Mackinnon]

In a world of mobile phones, I think you have to accept top posting, it’s just 
too hard to work otherwise on a small screen ... that said, quoting a small 
piece to reply to - is doable, and I think we can all try to do that?

Tim

Sent from my iPhone

> On 28 May 2018, at 07:26, Ben Coman  wrote:
> 
> 
> 
>> On 28 May 2018 at 11:48, Sean P. DeNigris  wrote:
>> Dear all,
>> 
>> There were several posts in the "Beacon for Pharo 7" thread which top-posted
>> on top of massive unsnipped quotes that were several-previous-posts deep.
>> IMHO this made the conversation impossible to follow. This issue has cropped
>> up from time to time in other threads. 
>> 
>> Please adhere to basic ML etiquette [1] to maximize our effectiveness. Two
>> essential guidelines are: 
>> 1) snip quoted material to just what's necessary to understand what's
>> being replied to 
>> 2) Post reply /after/ the quote from the OP, not before.
>> 
>> 1.
>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/etiquette.html#idp55179976
> 
> e.g... 
> 
> Because it messes up the order in which people normally read text.
> >Why is top-posting such a bad thing?   
> >>The lost context.
> >>>What makes top-posted replies harder to read than bottom-posted?
> Yes.
> >Should I trim down the quoted part of an email to which I'm replying?
> 
> http://www.idallen.com/topposting.html  
> 
> 
> Part of the problem is the way gmail and other clients *hide* the original 
> text behind three ellipses dots,
> so its not immediately obvious how much a thread has grown.
> Its good to make a habit of clicking those dots immediately after clicking 
> .
> 
> cheers -ben

Re: [Pharo-dev] files.pharo.org, get.pharo.org problems?

[Tim Mackinnon]

S3 is a great suggestion - but if we are part of google summer of code and an 
active open source platform - can’t they give a free reliable platform? 
Possibly amazon does similar?

Given we are often the source of so many formative ideas, can’t someone will 
help us sort the infrastructure?

If not, should one of us ask Martin Fowler or other Smalltalk advocates to help 
take this funding problem away. We need to pay engineers for the next 
generation of improvements?

Tim

Sent from my iPhone

> On 24 May 2018, at 17:49, Paul DeBruicker  wrote:
> 
> If it is a static site you can use this to manage it and host it on S3
> 
> 
> https://github.com/laurilehmijoki/s3_website
> 
> 
> 
> This is S3 pricing:
> 
> https://aws.amazon.com/s3/pricing/
> 
> 
> & calculator 
> 
> 
> http://calculator.s3.amazonaws.com/index.html
> 
> 
> 
> 
> 
> 
> 
> 
> Marcus Denker-4 wrote
>>> On 24 May 2018, at 14:19, Sean P. DeNigris 
> 
>> sean@
> 
>>  wrote:
>>> 
>>> Marcus Denker-4 wrote
 We need to think about finding another.
>>> 
>>> I've had success with https://www.siteground.com/ and
>>> http://www.namecheap.com for personal hosting, but can't say about bulk
>>> downloading…
>>> 
>> 
>> we use OVH, it is a web hosting contract. Maybe we need to use something
>> more expensive
>> (e.g. machine with certain bandwidth).
>> 
>>Marcus
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>