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

[Norbert Hartl]

Am 08.05.2024 um 16:14 schrieb Norbert Hartl :Am 06.05.2024 um 16:47 schrieb Dirk Nel :I'll definitely check it out..! and for those who are not in the know... what inspired the name? :)- I like the word- It has only four letters which qualifies as a class prefix- To me as a non-native speaker it means: ground layer you can build/grow on- people having fun with itMission accomplishedN.NorbertOn Wed, 24 Apr 2024 at 17:47, Tim Mackinnon  wrote: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.TimOn 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/SoilThis 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.orgTo unsubscribe send an email to esug-list-le...@lists.esug.org___
Esug-list mailing list -- esug-l...@lists.esug.org
To unsubscribe send an email to esug-list-le...@lists.esug.org

___Esug-list mailing list -- esug-l...@lists.esug.orgTo unsubscribe send an email to esug-list-le...@lists.esug.org

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

[Norbert Hartl]

> Am 06.05.2024 um 16:47 schrieb Dirk Nel :
> 
> I'll definitely check it out..! and for those who are not in the know... what 
> inspired the name? :)

- I like the word
- It has only four letters which qualifies as a class prefix
- To me as a non-native speaker it means: ground layer you can build/grow on

Norbert

> 
> On Wed, 24 Apr 2024 at 17:47, Tim Mackinnon  wrote:
>> 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 <http://pharo.org/>. 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 
>>> <mailto:esug-l...@lists.esug.org>
>>> To unsubscribe send an email to esug-list-le...@lists.esug.org 
>>> <mailto:esug-list-le...@lists.esug.org>
>>> 
>> 
>> ___
>> Esug-list mailing list -- esug-l...@lists.esug.org 
>> <mailto:esug-l...@lists.esug.org>
>> To unsubscribe send an email to esug-list-le...@lists.esug.org 
>> <mailto:esug-list-le...@lists.esug.org>

[Pharo-dev] Re: [Esug-list] [ANN] Pharo 12 released !

[Norbert Hartl]

Congratulation once again for this new release. Can‘t wait to put my hands onto it.NorbertAm 26.04.2024 um 12:19 schrieb Esteban Lorenzano :

  


  
  
Dear Pharo users and dynamic language lovers:
We have released Pharo version
  12!
What is Pharo?
Pharo is a pure object-oriented programming language and a
  powerful environment focused on simplicity and immediate feedback.


  Simple & powerful language: No constructors, no types
declaration, no interfaces, no primitive types. Yet a powerful
and elegant language with a full syntax fitting in one postcard!
Pharo is objects and messages all the way down.
  Live, immersive environment: Immediate feedback at any moment
of your development: Developing, testing, debugging. Even in
production environments, you will never be stuck in compiling
and deploying steps again!
  Amazing debugging experience: Pharo environment includes a
debugger unlike anything you've seen before. It allows you to
step through code, restart the execution of methods, create
methods on the fly, and much more!
  Pharo is yours: Pharo is made by an incredible community, with
more than 100 contributors for the last revision of the platform
and hundreds of people constantly contributing with frameworks
and libraries.
  Fully open-source: Pharo full stack is released under MIT License and
available on GitHub

... more on the Pharo
Features page.
In this iteration of Pharo, we continue working on our objectives
  of improvement, clean-up and modularization.
  Also, we included a number of usability and speed improvements.
  A complete list of changes and improvements is available in our Changelog
Some highlights of this amazing version:
Highlights
New breakpoint system
The debug point system is a breakpoint model that supersedes the
  previous implementation of breakpoints and watchpoints. They are
  configurable, composable, and extensible. The traditional
  breakpoints remain available, including conditional breakpoints,
  one-time breakpoints, and object-centric breakpoints.
  Additionally, there are new types of breakpoints, such as
  chained-breakpoints, which condition the activation of certain
  breakpoints on the triggering of others (e.g., breakpoint B only
  activates if breakpoint A is hit first). Debug points also feature
  a dedicated browser and integration options.

Tools

  Scalable fluid class syntax is now the default one
  Preparing the introduction of the Bloc graphic system by
migrating more tools to Spec2 widgets
  Spec2 UI framework enhancements to support GTK 4
  Leaner version of the Metacello package manager
  More robust and strict mode for FFI

System

  New architecture for refactorings and domain specific
transformations
  Code loading speed improvement
  Fast browsing via fully optimized package tags
  Optmized memory usage via optimized method protocols
  Compiler simplifications and improvements 

Virtual machine

  Massive image support with permanent space
  String/ByteArray comparison speed up

Development Effort
This new version is the result of 1895 Pull Requests integrated
  just in the Pharo repository.
  We have closed 865 issues and received contributions from more
  than 70 different contributors.
  We have also a lot of work in the separate projects that are
  included in each Pharo release:

  http://github.com/pharo-spec/NewTools
  http://github.com/pharo-spec/NewTools-DocumentBrowser
  http://github.com/pharo-spec/Spec
  http://github.com/pharo-vcs/Iceberg
  http://github.com/ObjectProfile/Roassal3
  http://github.com/pillar-markup/Microdown
  http://github.com/pillar-markup/BeautifulComments
  http://github.com/pharo-project/pharo-vm

Contributors
We always say Pharo is yours. It is yours because we made it for
  you, but most importantly because it is made by the invaluable
  contributions of our great community (yourself).
  A large community of people from all around the world contributed
  to Pharo 12.0 by making pull requests, reporting bugs,
  participating in discussion threads, providing feedback, and a lot
  of helpful tasks in all our community channels.
  Thank you all for your contributions.
The Pharo Team
Discover Pharo: https://pharo.org/features
Try Pharo: http://pharo.org/download
Learn Pharo: http://pharo.org/documentation

  

___Esug-list mailing list -- esug-l...@lists.esug.orgTo unsubscribe send an email to esug-list-le...@lists.esug.org

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

[Norbert Hartl]

Hi,Am 24.04.2024 um 19:28 schrieb Miloslav.Raus--- via Pharo-dev :







Wonderful to hear. Unless mistaken, SOIL should support multiple open databases , so unless you expect intra-database consistency,since
 „you’ll get an object back“, it should „just work“ for objects possibly instantiated from different DB’s ?I have trouble understanding what you mean. Can you elaborate on that?You mean multiple open databases on the same data on different images? As long as you don‘t use indexes it should work. But I think this is only a good option in very rare cases.Norbert
 


From: Norbert Hartl 

Sent: Wednesday, April 24, 2024 1:53 PM
To: Pharo users users ; Pharo Dev ; ESUG 
Subject: [Pharo-dev] [ANN] Soil release v1


 
...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

[Pharo-dev] [ANN] Soil release v1

[Norbert Hartl]

...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

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

[Norbert Hartl]

Thanks to all of you for the nice comments.

I wish you, pharo and the community all the best for 2024. In 2024 there will 
be a soil release that I promised for this year but I didn’t make it. 

Norbert

> Am 14.12.2023 um 15:19 schrieb Sven Van Caekenberghe :
> 
> 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: [Pharo-users] [ANN] Pharo 11 Released !

[Norbert Hartl]

Hurray! Congats to all of you for the hard work once more to bring it to life. 
And I like the picture that does not lie about us not having HiDPI 

Now I need to upgrade all of my stuff again !!

norbert

> Am 11.05.2023 um 13:39 schrieb Esteban Lorenzano :
> 
> Dear Pharo users and dynamic language lovers:
> 
> We have released Pharo  version 11!
> What is Pharo?
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment focused on simplicity and immediate feedback.
> 
> 
> 
> Simple & powerful language: No constructors, no types declaration, no 
> interfaces, no primitive types. Yet a powerful and elegant language with a 
> full syntax fitting in one postcard! Pharo is objects and messages all the 
> way down.
> Live, immersive environment: Immediate feedback at any moment of your 
> development: Developing, testing, debugging. Even in production environments, 
> you will never be stuck in compiling and deploying steps again!
> Amazing debugging experience: Pharo environment includes a debugger unlike 
> anything you've seen before. It allows you to step through code, restart the 
> execution of methods, create methods on the fly, and much more!
> Pharo is yours: Pharo is made by an incredible community, with more than 100 
> contributors for the last revision of the platform and hundreds of people 
> constantly contributing with frameworks and libraries.
> Fully open-source: Pharo full stack is released under MIT 
>  License and available on GitHub 
> 
> ... more on the Pharo Features page .
> 
> In this iteration of Pharo, we continue working on our objectives of 
> improvement, clean-up and modularization. Also, we included a number of 
> usability and speed improvements. A complete list of changes and improvements 
> is available in our Changelog 
> 
> Some highlights of this amazing version:
> Highlights
> 
> Tools
> Iceberg (the git client/VCS control tool) has received a lot of tweaks and 
> fixes to work better with GitHub and other Git services.
> Our debugger now incorporates lots of tweaks and notably the capability of 
> adding bindings in the context interaction model.
> The is a new implementation of rewrite tools and improved refactoring support.
> There is a new tool: The Document Browser, which presents Microdown (markdown 
> compatible) documents placed on the web or locally.
> New Tools presented in Calypso (the System Browser) and additional extended 
> Inspectors.
> All versions of NewTools, Spec, Roassal and Microdown have been updated with 
> their respective bug fixes and improvements.
> System
> Extended Full Blocks and Constant Clock closures support.
> Additional Inlining and optimizations
> Bug Fixes and Clean up.
> Ephemeron Finalization support.
> Virtual machine
> Ephemerons Production Ready.
> Initial support for Single-Instruction Multiple-Data (SIMD).
> Third-Party Dependency Update (Newer versions, Graphic Libraries using 
> Hardware Acceleration).
> Clean Ups: Remove lots of old code, notably old experiments, and dead code.
> Development Effort
> 
> This new version is the result of 1412 Pull Requests integrated just in the 
> Pharo repository. We have closed 972 issues and received contributions from 
> more than 70 different contributors. We have also a lot of work in the 
> separate projects that are included in each Pharo release:
> 
> http://github.com/pharo-spec/NewTools 
> http://github.com/pharo-spec/NewTools-DocumentBrowser 
> 
> http://github.com/pharo-spec/Spec 
> http://github.com/pharo-vcs/Iceberg 
> http://github.com/ObjectProfile/Roassal3 
> 
> http://github.com/pillar-markup/Microdown 
> 
> http://github.com/pillar-markup/BeautifulComments 
> 
> http://github.com/pharo-project/pharo-vm 
> 
> Contributors
> 
> We always say Pharo is yours. It is yours because we made it for you, but 
> most importantly because it is made by the invaluable contributions of our 
> great community (yourself). A large community of people from all around the 
> world contributed to Pharo 11.0 by making pull requests, reporting bugs, 
> participating in discussion threads, providing feedback, and a lot of helpful 
> tasks in all our community channels. Thank you all for your contributions.
> 
> The Pharo Team
> 
> Discover Pharo: https://pharo.org/features
> Try Pharo: http://pharo.org/download
> Learn Pharo: http://pharo.org/documentation

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

[Norbert Hartl]

It is just incredible what happens in one week in the pharo community. 
This is really great!

Thank you all for your efforts!

Norbert

> Am 31.03.2023 um 12:18 schrieb Marcus Denker :
> 
> We again merged ~60 PRs. 
> 
> Pharo11 got some bugfixes and last improvements.
> 
> In Pharo12, we continue the compiler refactoring and the cleanup of 
> ClassOrganizer. 
> 
> 
> Pharo11
> ===
> 
> 
> Last Improvements
> =
> 
> - Add a way to know the real processor architecture #13124
>   https://github.com/pharo-project/pharo/pull/13124
>   
> - remove end line characters in returned value of processorArchitecture #13155
>   https://github.com/pharo-project/pharo/pull/13155
>   
> - Removing unused instance variable topContext in DebugContext #13179
>   https://github.com/pharo-project/pharo/pull/13179
>   
> - Add inspector extensions for Chronology #499
>   https://github.com/pharo-spec/NewTools/pull/499
>   
> - More inspector extensions #497
>   https://github.com/pharo-spec/NewTools/pull/497
>   
> 
> Fixes
> =
> 
> - 13181-DeprecationPerformedNotification-Automatic-deprecation-code-rewrite 
> #13182
>   https://github.com/pharo-project/pharo/pull/13182
>   
> - implement #selectedClassOrMetaClass in MCTool to return nil #13167
>   https://github.com/pharo-project/pharo/pull/13167
>   
> - 13141-timesRepeat-does-not-work-on-nested-loops #13154
>   https://github.com/pharo-project/pharo/pull/13154
>   
> - 13122 rbparser cutting tokens in stepBar [Pharo11] #13129
>   https://github.com/pharo-project/pharo/pull/13129   
>   
> - fixing the code update bug after compiling a missing method with the 
> unfiltered stack #491  
>   https://github.com/pharo-spec/NewTools/pull/491
>   
> - Categorizing uncategorized classes in new tools debugger tests #500
>   https://github.com/pharo-spec/NewTools/pull/500
>   
> - SpCodeInteractionModel>>#notify: Avoid crashing #1363
>   https://github.com/pharo-spec/Spec/pull/1363
>   
> - SpDropListExampleTest does not opens Playgorunds anymore #1359
>   https://github.com/pharo-spec/Spec/pull/1359
> 
>   
> Pharo12
> ===
> 
> Speed
> =
> 
> - speedup-testNoShadowedVariablesInMethods #13170
>   https://github.com/pharo-project/pharo/pull/13170
>   
> - Speed up #assertCollection:hasSameElements: in case they are equals. #13144
>   https://github.com/pharo-project/pharo/pull/13144
> 
> 
> ClassOrganizer Cleanup
> ==
> 
> - Inline extensions of protocol organizer #13194
>   https://github.com/pharo-project/pharo/pull/13194
>   
> - ChangeRecord: rename category into protocol #13188
>   https://github.com/pharo-project/pharo/pull/13188
>   
> - Inline some protocol organizer behavior #13191
>   https://github.com/pharo-project/pharo/pull/13191
>   
> - remove commentSourcePointer from ClassOrganization #13176
>   https://github.com/pharo-project/pharo/pull/13176
>   
> - Set-CommentSourcepointer-ClassDescription #13171
>   https://github.com/pharo-project/pharo/pull/13171
>   
> - Update behaviour of #protocolNamed: #13173
>   https://github.com/pharo-project/pharo/pull/13173
>   
> - Simplify and deprecate ClassDescription>>allProtocolsUpTo: #13160
>   https://github.com/pharo-project/pharo/pull/13160
>   
> - ProtocolOrganizer cleanings #13169
>   https://github.com/pharo-project/pharo/pull/13169
>   
> - ClassComments-Via-Class #13168
>   https://github.com/pharo-project/pharo/pull/13168
>   
> - Rename #nullCategory into #nullProtocolName #13157
>   https://github.com/pharo-project/pharo/pull/13157
>   
> 
> Compiler Cleanup
> 
> 
> - Remove RBInstanceVariableNode crufts #13199
>   https://github.com/pharo-project/pharo/pull/13199
>   
> - Faulty code: Make OCUndeclaredVariableWarning a little less special #13186
>   https://github.com/pharo-project/pharo/pull/13186
>   
> - Compiler source code is String #13184
>   https://github.com/pharo-project/pharo/pull/13184
> 
> - Factorize recompile:from: #13180
>   https://github.com/pharo-project/pharo/pull/13180
>   
> - OpalCompiler gain install #13152
>   https://github.com/pharo-project/pharo/pull/13152
>   
> - Faulty code: improve code error descriptions #13174
>   https://github.com/pharo-project/pharo/pull/13174
>   
> - Faulty code: make OCASTSemanticAnalyzer (almost) faulty only #13165
>   https://github.com/pharo-project/pharo/pull/13165
> 
> - CodeImport - stop requestor madness #13162
>   https://github.com/pharo-project/pharo/pull/13162
> 
> - Faulty code - signal mainly CodeError #13164
>   https://github.com/pharo-project/pharo/pull/13164
>   
> - Faulty code improve scanner on error tokens #13135
>   https://github.com/pharo-project/pharo/pull/13135
>   
> - Faulty code: 

[Pharo-dev] Re: Pharo VM Release - v10.0.0

[Norbert Hartl]

This is yet again an impressive list of good things. Always appreciated are 
"Remov*" features :)

I'm especially interested in ephemerons and how it improves the weak structures 
in the image. Hope the image support that makes use of the vm features follows 
soon.

A wish would be to know a bit more about the permanent space news. 

Great work as always. Thanks!

Norbert

> Am 01.03.2023 um 11:26 schrieb teso...@gmail.com:
> 
> Hello, 
>   we have released a new version of the Pharo VM for Pharo 11. This VM is 
> accessible right now from Zero-Conf, updating it in the Pharo Launcher or 
> using the usual downloads (as described in pharo.org/download 
> ). OBS packages are still in work and will come 
> later. 
> 
> This is the new VM that will be stable for Pharo 11 release, it is also 
> compatible with Pharo 10 images but it is not the default for Pharo 10.
> 
> It has a lot of changes and improvements, as it is the result of more than a 
> year and a half of improvements, clean-ups, and bug fixes.
> 
> Changelog v10.0.0
> 
> - Slang (Smalltalk to C Translator)
> - Introducing a C AST to ease the generation of C Code
> - Having a Pretty Printer for C AST
> - Translation Tests
> - Fixing Translation Issues
> - Clear separation between Slang and VM code
> - Improving Cast generation
> 
> - Clean Up: 
> - Remove Old Bytecode Set
> - Remove Old Block Implementation
> - Simplification of the Primitives
> - Removing Unused / Old Code / Dead Code
> - Cleanup / Removal of Old Unused primitives
> - Removing Old FFI Implementation
> - Removing MT Experiment from the code base (Kept in own branch)
> - Fixing Compilation Warnings
> - Improving Type annotations to fix bugs in the translation / compilation
> - Removing Conditional Code on Old Configurations / Features
> - Renaming Concepts to be inline with Common terminology
> - Remove Newspeak, Multiple Bytecode and Old Memory Managers
> - Removing Unused Plugins
> 
> - Tests
> - GNUification Tests
> - Tests for Math primitives including overflow and conversion testing.
> - Tests for comparison primitives (Equals / Not Equals / Less than / Less or 
> Equals / Greater Than / Greater or Equals)
> - Testing Primitives for objects Pinned in Memory
> - Testing Math Primitives for Immediate Classes (SmallFloats / SmallIntegers) 
> - Improving Simulation Infrastructure
> - Using Sista Bytecode in all Tests
> - Updating Unicorn version
> - Improving Machine Code emulation
> - Testing Image Read / Image Write
> - Using the same memory map in Tests and Execution
> - Testing Ephemerons
> - Become Primitives
> 
> - Ephemeron
> - Fix for large ammounts
> - Make it available
> - Testing Signal Finalizations
> 
> - Fixing Become Errors.
> 
> - Fixing XRay Primitive
> 
> - Single-Instruction Multiple-Data (SIMD) initial Support:
> - Initialization of new objects using SIMD (ARM64)
> - Adding Bytecode Extensions to support SIMD instructions
> - Adding Vector Registers
> - Vector Register bytecodes
> 
> - Auto Localization of Interpreter loop variables and edge detection 
> simplifying development and minimizing code
> 
> - ImageReader / ImageWriter reification needed for Permanent Space.
> 
> - Improving the Memory Map of the VM (Using constant positions)
> 
> - Dependencies Improvements
> 
> Thanks a lot, and any doubt please let us know.
> Cheers, 
> 
> Pablo on behalf of the whole Pharo team
> 
> --
> Pablo Tesone.
> teso...@gmail.com 

[Pharo-dev] Re: [Pharo-users] Pharo VM Release - v9.0.21

[Norbert Hartl]

Thanks Pablo for the new vm but as well for the update notification. This is 
super valuable.

Norbert

> Am 12.12.2022 um 14:30 schrieb teso...@gmail.com:
> 
> Hello, 
>   I have released a new version of the Pharo VM for Pharo 9, Pharo 10 and 
> Pharo 11. This VM is accessible right now from Zero-Conf, updating it in the 
> Pharo Launcher or using the usual downloads (as described in 
> pharo.org/download ). 
> 
> This version includes a series of bug fixes and upgrades on the third-party 
> libraries.
> 
> Changelog: 
> 
> - Implementing High resolution clock for ARM64 (Used during profiling)
> - Updating third party libraries for all the graphic layer.
> - Fixing a performance regression on the allocation of opcodes and fix-ups.
> Cleaning only the ones that are going to be used.
> Like this, this version has the same speed than before when 
> allocating in the stack.
> - Correctly handling the encoding of the command line arguments of the VM 
> (Windows)
> - Allocating the opcodes and fixup structs only once and reusing them 
> (Reducing risk of C Stack Overflow)
> 
> Thanks a lot, and any doubt please let me know.
> Cheers, 
> 
> Pablo on behalf of the whole Pharo team.
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com 

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

[Norbert Hartl]

hi Yanni,

> Am 12.08.2022 um 07:25 schrieb Yanni Chiu :
> 
> Sounds good. Using Fuel to serialize/deserialize should be fine, but I had 
> unhappy experience with early versions where a newer Fuel version could not 
> read content written by earlier Fuel versions.

That is indeed the weakest part of Fuel I know and something I need to take 
care off. I will use Fuel without that part of the header that barks on 
versions. What needs to be done is to see what changed between versions and 
make a way to migrate. For this the database files will most likely have a 
version that is dedicated to the Fuel version being used.  

> 
> In my mind, a disk-based B-tree is the fundamental data structure for any 
> database (e.g. GemStone, Omnibase, Relational DBs all have it), but I don’t 
> see it mentioned so far. Everything else about a "database" is optional, IMHO.
> 

Ah, right, I didn't write about it but it is essential. My plan would be to 
also have a disk based b-tree dictionary that can keep parts like the keys 
(maybe even incrementally) in memory. But I'm not an expert in b-trees so I 
need to figure out what is the gap between the requirements of a b-tree and my 
plans ;) Also b-tree will come later after you are able to write/read something 
reliable.

> For example, a query language is not needed at all, if the data items are 
> equivalent to objects running in a Smalltalk VM - the query language is 
> Smalltalk itself. It “just” has to mesh well with the indexing.
> 
I think it needs a query DSL. Using blocks has serious limitations doing a 
proper query. The usage of instVars needs to be well known in order to analyze 
a query for index usage. Furthermore is the problem like #collect:thenSelect: 
even more severe in a database. So for indexes and query optimizations it 
should be a query DSL that is more like 

aCollection select firstName = 'Norbert'

I will experiment a bit. The combination of multiple queries in smalltalk and 
using binary messages is a problem of its own.

> Another feature is MVCC. How much concurrency is needed, and how it is 
> implemented, is an implementation choice. I’d mentioned LMDB on Discord. It 
> has single writer, many readers. Choosing to have multiple simultaneous 
> writers has a cost. When there is one or more big machines, it seems sensible 
> have the big machines use multiple writers. But when these databases scale 
> up, the database ends up sharded, with parts of the data spread over multiple 
> machines. Why not just start there, with many small machines owning a small 
> part of the database, and use just a single writer process. The application 
> can then deal with concurrency, conflicts and assembling results, in whatever 
> manner best suits.
> 
Almost all databases have only a single writer for one set of data. Sharding is 
a way to have virtual partitions of your data where you can have a writer per 
virtual partition removing the conflit potential. MVCC is not about having 
multiple writers as it is hardly possible. The benefits of MVCC are that data 
in a transaction is fully isolated and writers do not block readers. I 
personally like that a MVCC database is an append-only store for object data. 
You have to have one concurrency approach and MVCC is not really hard to 
implement. 
In ApptiveGrid we have a fully partioned model per user where 
inter-user-references use URNs as content address notation. This way we have 
hundreds of databases where each has a single writer. This is my main focus but 
I think we are on the same page regarding that. If nothing changes my talk at 
ESUG will talk about this.

> So I see the end goal to be a set of frameworks, and some “recipes” for 
> putting the frameworks together, to solve the “persistence” problem. These 
> are just half-baked ideas of course. I’ll follow the project, and hope to 
> contribute.

Thanks. I don't how far this project will get. But I have a need and ideas. 
Just need time :)

Let's see where the journey gets.

Norbert

> 
> Yanni
> 
> On Wed, Aug 10, 2022 at 7:08 AM Norbert Hartl  <mailto:norb...@hartl.name>> wrote:
> FYI
> 
> As the license situation around Omnibase is unlikely to change and such a 
> license is not an enabler for collaboration I came to the conclusion that 
> there is no other way than to start a new OO database (what a surprise! :) )
> 
> If you are interested or want to see what will happen in the next months you 
> can have a look at 
> 
> https://github.com/ApptiveGrid/Soil <https://github.com/ApptiveGrid/Soil>
> 
> After half a day of work it can already serialize and partition a simple 
> graph and store it to disk in a way it can be read back even when 
> partitioned. Thanks to having Fuel we do not need to reinvent the wheel and 
> have serialization/materialization done. 
> Of cours

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

[Norbert Hartl]

FYI

As the license situation around Omnibase is unlikely to change and such a 
license is not an enabler for collaboration I came to the conclusion that there 
is no other way than to start a new OO database (what a surprise! :) )

If you are interested or want to see what will happen in the next months you 
can have a look at 

https://github.com/ApptiveGrid/Soil <https://github.com/ApptiveGrid/Soil>

After half a day of work it can already serialize and partition a simple graph 
and store it to disk in a way it can be read back even when partitioned. Thanks 
to having Fuel we do not need to reinvent the wheel and have 
serialization/materialization done. 
Of course this is super simple and does not comes close to anything usable but 
a good start. I've also added a documentation in the github repo to describe 
the most important parts for me that I will target.

Questions, critiques and laughs are appreciated,

Norbert

> Am 08.08.2022 um 15:18 schrieb Norbert Hartl :
> 
> 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 
> <https://github.com/ApptiveGrid/MoniBase>
> 
> and 
> 
> https://github.com/pharo-nosql/OmniBase 
> <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: Omnibase/Monibase repository removal

[Norbert Hartl]

Hi Dale,

thanks for the pointer.  I always admired what the GemStone people did and do. 
But I'm looking for something more lightweight and more easy to handle approach 
this time. Well, from the github page I could not derive what it really does to 
be honest.

Hope to see you at ESUG,

Norbert

> Am 08.08.2022 um 18:44 schrieb Dale Henrichs 
> :
> 
> Norbert,
> Before you go off and invent a data base, you might take a look at GemStone 
> and RemoteServiceReplication[1] ...
> 
> Dale
> 
> [1] https://github.com/GemTalk/RemoteServiceReplication 
> <https://github.com/GemTalk/RemoteServiceReplication>
> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl  <mailto:norb...@hartl.name>> 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 
> <https://github.com/ApptiveGrid/MoniBase>
> 
> and 
> 
> https://github.com/pharo-nosql/OmniBase 
> <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] Omnibase/Monibase repository removal

[Norbert Hartl]

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: [Pharo-users] Pharo-vm mailing-list

[Norbert Hartl]

Good move. There should be more interest in vm topics.

thanks,

Norbert

> Am 01.07.2022 um 22:47 schrieb stephane ducasse :
> 
> Hi 
> 
> Since a couple of years the Pharo crew has been working on the Pharo-vm and 
> most of the communication was using internal channels. 
> 
> Now that the community is growing we believe that it is important to have a 
> public way to communicate around the VM and our current and future 
> developments. 
> 
> We are happy to announce that we set up a mailing-list for the Pharo-vm.
> 
> https://lists.pharo.org/list/pharo-vm.lists.pharo.org 
> 
> 
> Stef on the behalf of the Pharo lille crew.
> 
> 
> 

[Pharo-dev] Re: About Image Size Pharo9->Pharo11

[Norbert Hartl]

This is gold. This is the work nobody usually likes to do but is THE apsect for 
sustainability of a system.

Like it!!!

thanks,

Norbert


> Am 11.05.2022 um 09:00 schrieb Marcus Denker :
> 
> Pharo9: 65,8 MB
> Pharo10: 57,4 MB
> Pharo11: 56,5 MB
> 
> The space saving come from three things:
> 
> 1) Code cleanup Pharo9-Pharo10
> =
> 
> e.g. removal of support in Kernel and Compiler of old style blocks and 
> bytecodes, 
> to mention one smaller (in term of image size) but deep cleanup.
> 
> Of course, we can do more here. There is still a lot of dead code (and 
> duplicated
> things) in the image!
> 
> 
> 2) Global Literal Sharing
> ===
> 
> Literals are now, when the method is compiled, set to be read-only, 
> recursively in the case of arrays.
> 
> This allows us to unify (share one instance) not only in the same method, but 
> globally over all methods.
> 
> As the compiler can not do a global literal table when compiling a single 
> method (too slow), this is implemented 
> as an additional pass, called as part of the build process.
> 
> If you load a lot of code, it might be an idea to do that as part of your 
> build again:
> 
>   ImageCleaner shareLiterals
>   
>   
> 3) Improvement of code structure objects
> ===
> 
> e.g, in Pharo10 we found two empty OrderedCollections per class that where 
> not needed. 
> 
> Further work on this idea is where the improvement in Pharo11 comes from, we 
> merged these three changes:
> 
> - Class>>#classPool: empty dictionary for all classes, but not many define 
> class vars #11172
>   https://github.com/pharo-project/pharo/issues/11172
>   
> - [Memory] sharedPools OrderedCollections waste memory #10957
>   https://github.com/pharo-project/pharo/issues/10957
>   
> - [Memory] AllProtocol uses a lot of memory #10963
>   https://github.com/pharo-project/pharo/issues/10963
>   
> 
> The classPools/sharedPool improves the size of the bootstrapped image not to0 
> much as the boostrap creates
> classes with nil there, but for newly loaded code this will be more visible.
> 
> This direction has some more fairly simple next steps:
> 
> - [Memory] commentSourcePointer is not needed for MetaClasses
>   https://github.com/pharo-project/pharo/issues/10958
>   
> - [Memory] Every class and meta class has both a ProtocolOrganizer and a 
> ClassOrganization #10959
>   https://github.com/pharo-project/pharo/issues/10959
> 
> 
> ... and of course there are many more things to find with just looking a bit. 
> 
> (And it is interesting starting point to think about better language support 
> for making long living but rarely changed
> data structures more memory efficient)
> 
> If you want to get an impression of which classes use image space, 
> "SpaceTally printSpaceAnalysis"
> prints a per-class analysis.
> 
>   Marcus

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

[Norbert Hartl]

Congratulations! I‘m happy that finally the image lost some of the deprecated 
things.

Great work! I could migrate our product today to pharo10 in less than 90 
minutes. While all the time went into docker, jenkins and all the 
infrastructure stuff. Only a single thing I needed to change because my code 
did not handle Deprecations.

I hope we can keep the release cycle as short as this.

Norbert

> Am 05.04.2022 um 12:41 schrieb Esteban Lorenzano :
> 
> 
> 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: [Pharo-users] [ANN] Pharo 9 released!

[Norbert Hartl]

Great news! Finally it arrived. Big changes happened and this release might 
feel a bit rough. But that is expected. And we should not underestimate the 
value of moving all tools to spec. That makes all of it (yet again) less 
dependent in morphic. Having an idle vm is also highly appreciated for peole 
like me that do a lot of server installations.

Well done and thanks for the hard work!

Norbert

> Am 15.07.2021 um 11:15 schrieb Esteban Lorenzano :
> 
> 
> Dear World and dynamic language lovers: 
> 
> The time has come for Pharo 9 !
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> 
> 
> Here are the key features of Pharo 9:   
> 
> Full redesign of the Spec UI framework (new logic, application, style, GTK3 
> back-end)
> New tools:
> new playground,
> new object centric inspector,
> new object centric debugger.
> better and new Refactorings
> class comments are now written in Microdown format (Markdown compatible)
> classes now can be defined using a "fluid" api (Preview)
> New completion framework that adapts better to edition contexts and is 
> customizable
> Fast universal non-blocking FFI which now uses libFFI as backend.
> Pharo now supports Windows, OSX, Linux (Ubuntu, Debian, Fedora, openSUSE, 
> Arch, Raspbian) and multiple architectures (Intel/ARM 32/64bits).
> Virtual Machine
> Idle VM
> Support for ARM 64bits
> Support for Apple M1
> More than 3000 tests
> Built for Ubuntu 18.04, 19.04, 20.04, 21.04, 21.10; Debian 9, 10, Testing; 
> Fedora 32, 32, 34; openSUSE 15.1, 15.2, Tumbleweed; Manjaro; Arch
> Uses SDL 2.0 as back-end by default. It supports extended event handling, 
> including trackpad support.
> General speed up due to compiler optimisations and UI simplification.
> And many, many more tests.
> 
> These are just the more prominent highlights, but the details are just as 
> important. We have closed a massive amount of issues: around 1400 issues and 
> 2150 pull requests.
> 
> A more extended changelog can be found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo90ChangeLogs.md.
> 
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 9 image was contributed 
> by more than 90 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, Ale Cossio, Alexandre Bergel, 
> Alistair Grant, Allex Oliveira, Angela Chia-Ling, Arturo Zambrano, Asbathou 
> Biyalou-Sama, Ben Coman, Benoit Verhaegue, Carlo Teixeira, Carlos Lopez, 
> Carolina Hernandez, Charles A. Monteiro, Christoph Thiede, Christophe 
> Demarey, Clotilde Toullec, Cyril Ferlicot, Damien Pollet, Daniel Aparicio, 
> David Bajger, David Sánchez i Gregori, Denis Kudriashov, Ellis Harris, Eric 
> Brandwein, Eric Gade, Erik Stel, ErikOnBike, Esteban Lorenzano, Esteban 
> Villalobos, Evelyn Cusi Lopez, Evelyn Cusi Lopez, Ewan Dawson, Francis 
> Pineda, Francis Pineda, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni 
> Corriga, Guille Polito, Himanshu jld, Johan Brichau, Jonathan van Alteren, 
> Jordan Montt, Julien Delplanque, Kamil Kukura, Kasper Østerbye, Kurt Kilpela, 
> Laurine Dargaud, Marco Rimoldi, Marcus Denker, Martin Dias, Martin McClure, 
> Massimo Nocentini, Max Leske, Maximilian Ignacio Willembrinck Santander, 
> Milton Mamani Torres, Moussa Saker, Myroslava Romaniuk, Nicolas Anquetil, 
> Norbert Hartl, Nour Djihan, Oleksandr Zaitsev, Pablo Sánchez Rodríguez, Pablo 
> Tesone, Pavel Krivanek, Philippe Lesueur, Pierre Misse, Rakshit P., Rob 
> Sayers, Roland Bernard, Ronie Salgado, Sean DeNigris, Sebastian Jordan 
> Montaño, Serge Stinckwich, Stephan Eggermont, Steven Costiou, Stéphane 
> Ducasse, Sven Van Caekenberghe, Thomas Dupriez, Théo Lanord, Théo Rogliano, 
> Todd Blanchard, Torsten Bergmann, Vincent Blondeau, Wéslleymberg Lisboa.
>  
> 
> (If you contributed with Pharo 9 development in any way and we missed your 
> name, please send us an email and we will add you).
> 
> Enjoy!
> 
> The Pharo Team
> 
> Try Pharo: http://pharo.org/download
> 
> Learn Pharo: http://pharo.org/documentation

[Pharo-dev] Re: [ANN] Freezing Pharo 9 development right now :)

[Norbert Hartl]

Very good! Does it mean the release will be around august?

Norbert


> Am 30.04.2021 um 23:04 schrieb Esteban Lorenzano :
> 
> Hi,
> 
> So, today I was checking how much it is missing for release and what is our 
> status, and I realized if we do not freeze now, we will never release in a 
> reasonable time.
> So, even if there are a couple of cleanups and that to still do that should 
> happen before, I will declare that Pharo 9.0 enters in freeze Pharo 9.0 right 
> now (and I will sneak the cleanups anyway, but being more careful).
> 
> What does this means?
> No more features, just bugfixes
> No more fixes of things that can wait until Pharo 10
> 
> In two weeks I will open the Pharo 10 development branch, up to then, please 
> help fixing what's missing (which is a lot) !
> 
> Have a great weekend,
> 
> cheers!
> Esteban

[Pharo-dev] Re: [Pharo-users] Pharo - GSOC 2021

[Norbert Hartl]

Great! This is to be accepted as organization? Projects still have to be 
accepted IIRC. Right?

Norbert

> Am 11.03.2021 um 07:33 schrieb Serge Stinckwich :
> 
> Dear all,
> 
> great news I want to share with you: Pharo has been selected to be part of 
> GSOC 2021
> 
> https://summerofcode.withgoogle.com/organizations/?sp-search=pharo#4667274369171456
>  
> 
> 
> Thank you to the great team of admins for making this happen: Oleksandr 
> Zaitsev, Gordana Rakic and Juan Pablo Sandoval Alcocer !
> 
> We will send updates soon on the student selection process soon.
> Regards,
> -- 
> Serge Stinckwich
> https://twitter.com/SergeStinckwich 

Re: [Pharo-dev] Robust Functionality vs. Minimalism (was "Microdown ?")

[Norbert Hartl]

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] Microdown ?

[Norbert Hartl]

Microdown is a subset of markdown that can parse to a pillar model. So the 
discussions about pillar markup have finally settled and we have a syntax 
format that reads well in ascii which can be used in class comments even if it 
is a basic image.
To integrate pillar core in pharo is not new just the change in syntax. 

> Am 07.07.2020 um 11:27 schrieb Sven Van Caekenberghe :
> 
> Hi,
> 
> What is microdown ?
> What are its goals and objectives ?
> Where does it come from ?
> Is there any documentation about it ?
> 
> There probably is a background story here, and it is probably a good idea, 
> but unless I missed something, for me reading the mailing lists daily, it 
> came from nowhere and got immediately integrated into Pharo 9.
> 
> Sven
> 
> 

[Pharo-dev] [ANN] PharoPro

[Norbert Hartl]

Dear community,

we are very proud to announce the availability of PharoPro, a company that 
offers professional support for the pharo platform. Our mission is to enable 
people and companies to secure their business when building products with pharo.

We have been tinkering with the idea creating it for a long time. We talked to 
a lot of people, especially at last ESUG in cologne and finally decided to do 
it. So at the end of last year we founded the company PharoPro. Obstacles (one 
being covid-19) kept us from make it public until today.

In close relationship with the pharo consortium our mission is to extend the 
market opportunities for pharo.
Although PharoPro is new and still small we want to show our commitment to the 
consortium and the community from the start. We decided therefor that PharoPro 
will join the pharo consortium as platinum member.

Our plans apart from support contracts is to have an LTS (long term support) 
version of pharo, create a professional pharo ecosystem with libraries and 
frameworks and to help out building the infrastructure pharo needs.

We are still shaping up. We want to know your requirements and needs that help 
us deciding what are the most needed things. So you might visit

http://pharo-pro.com

and then come talk to us.

Best regards and health,

Norbert
PharoPro GmbH

Re: [Pharo-dev] OpenSSL binding Re: About strange email related to smalltalkhub read-only on squeak-dev

[Norbert Hartl]

> Am 04.06.2020 um 02:44 schrieb Pierce Ng :
> 
> On Tue, Jun 02, 2020 at 11:17:30AM +0200, Norbert Hartl wrote:
>> PierceNg has an implementation that implements a subset of openssl.
>> This implementation is modeled after the library so lots of class
>> methods. I'd prefer to have something more object model like. 
> 
> A very small subset currently, as my original need was to create an X509
> request in code. PRs welcome.
> 
>  https://github.com/PierceNg/OpenSSL-Pharo
> 
If it is a small subset it might be feasible to talk about the approach taken. 


Norbert

Re: [Pharo-dev] [Pharo-users] About strange email related to smalltalkhub read-only on squeak-dev

[Norbert Hartl]

Stef,

that is a second problem. The main problem to me is solving the crypto stuff 
once and for all. And then I would like to know why people like Ron say things 
like this.

But yes, shouldn't go without explanation/reaction!

Norbert


> Am 03.06.2020 um 00:13 schrieb Stéphane Ducasse :
> 
> What I do not like is that people say " group but they keep kicking me out of 
> their mailing list ” when this is absolutely not true!
> 
> We can discuss and can argue even violently but we do not lie. 
> 
> S. 
> 
> 
> 
>> On 31 May 2020, at 19:38, Bruce O'Neel > > wrote:
>> 
>> 
>> Hi,
>> 
>> So addressing only the crypto software issue and with the caveat that I am 
>> also not a lawyer but I have had to deal with certain aspects of this in the 
>> past
>> 
>> Crypto software is one of those bizarre dual use items in terms of arms 
>> imports and exports.  While we as geeks just think of this is software or 
>> mathematics and might be confused as to why governments care, governments do 
>> care deeply about this.  And their way of expressing how much they care 
>> about this issue is by passing laws and prosecuting folks.
>> 
>> One of the easiest ways to get in trouble is for one to make the software 
>> available to residents and/or citizens of certain countries as well as 
>> available to people on a long list kept by different governments.  We can 
>> have a long debate about the morality of this concept but those who make the 
>> laws have decided that is the law.  And often these laws are crafted such 
>> that the executive can change important details on short notice and that 
>> puts the risk of prosecution at the whims of different world leaders.  
>> 
>> The license that the software is released under is not important.   
>> 
>> What Ron is stating is that squeak source supplied some additional 
>> protections to prevent accidentally making the software available to folks 
>> who the US feels should not have access.
>> 
>> If you have moved the software to another hosting provider without the 
>> permission or knowledge of the author, and therefore the owner of the 
>> software, you have put that person at additional risk.  In addition you and 
>> the hosting provider are taking on additional risk.
>> 
>> If it was moved to GitHub I strongly recommend reviewing their policies on 
>> trade controls and what risks you assume.
>> 
>> https://help.github.com/en/github/site-policy/github-and-trade-controls 
>> 
>> 
>> Finally I would strongly recommend talking to a competent legal advisor who 
>> is deeply familiar with the details of these laws.  They are complex and 
>> highly variable between different parts of the world.
>> 
>> I know this seems like a lot of trouble and wasted time but you can spend a 
>> giant amount of time and money defending oneself from arms trafficking 
>> charges.
>> 
>> cheers
>> 
>> bruce
>> 
>> 30 May 2020 14:43 Stéphane Ducasse > > wrote:
>> Hi all
>> 
>> This is the week-end and we worked super well yesterday during the sprint. 
>> Lot of good enhancements - Thanks a lot to all the participants. 
>> I not really happy to be forced to do it on a sunny saturday but I’m doing 
>> it to clarify points.
>> 
>> Esteban sent me this text that was posted on Squeak-Dev (I personally do not 
>> read squeak related forums because 
>> I have not the time and my focus is Pharo, its consortium, my team, my 
>> research and my family). 
>> 
>> We have to react because 
>> - We do not really at ***all** understand this email
>> - We did not kicked anybody from our mailing-list from ages - so ron is 
>> lying. In the past we even had discussion with ron - so we do not 
>> really understand. May be we got problem to log on our mailing-lists. 
>> We have no idea because we are working and not looking at such things.   
>> - When we migrated smalltalkhub to readonly we payed attention to make sure 
>> that private projects stay private.
>> We did not migrated smalltalkhub for fun. We MUST do it or it will be done 
>> by our infrastructure!
>> - Now the cryptography packages are MIT and they are public anyway. So again 
>> we do not understand anything. 
>> 
>> We do not get why Ron contacted us because we announced the migration 
>> publicly way in advance and we will keep 
>> the Smalltalkhub frozen repo for at least next 5 years. 
>> 
>> I feel really sorry to hear such kind of email because we do not want to 
>> fight with anybody. 
>> Our goal is to make sure that people can work with Pharo and expand their 
>> business and knowledge. 
>> We are working hard to make sure that people can invent their future with 
>> Pharo and people that know us personally 
>> know that we are not lying.
>> 
>> S
>> 
>> 
>> 
>>> Hi all,
>>> 
>>> I've tried to work with the Pharo group but they keep kicking me out of 
>>> their mailing list.  I've already 

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

[Norbert Hartl]

Hi Paul,

thanks for the info but I won't read it. I try to focus on things that matter. 
There are too many things that try to distract everyone from producing 
something helpful. Law suits are IMHO not of that kind. 

I would rather put some money on the table for someone building proper FFI to 
openssl. The Cryptography was a mess I cleaned a bit but I had also scenarios 
where the squeak code was not working properly. And there is no real reason to 
have a smalltalk implementation of crypto if we carry around openssl anyway 
(for iceberg and secure connects).

PierceNg has an implementation that implements a subset of openssl. This 
implementation is modeled after the library so lots of class methods. I'd 
prefer to have something more object model like. 

So if you think you can implement this please contact me and tell me what you 
think how long it takes and how much it will cost to do at least the things we 
have now in Cryptography. I'm willing to collect money or pay it myself.

Norbert

> Am 31.05.2020 um 16:04 schrieb Paul DeBruicker :
> 
> Hi Norbert,
> 
> The EFF gives a nice overview of the US situation:
> https://www.eff.org/deeplinks/2019/08/us-export-controls-and-published-encryption-source-code-explained
>  
> 
> 
> Although you are not a US citizen, and don't live here,  so I don't know how
> it could affect you.  
> 
> In the link above the EFF does say they provide free consultations about
> this topic so I'm sure someone there will clear things up for you.
> 
> Paul
> 
> 
> 
> 
> 
> 
> NorbertHartl wrote
>> Yes, let us coordinate what to respond. To me this doesn't even sound like
>> Ron. Usually he is a rather quite and reasonable guy. Seems to be a lot of
>> misunderstandings here (again).
>> As I was the one copying the Cryptography package to github it concerns me
>> a bit. I've been remembered now about yet another strange law suit in the
>> US and indeed we need to raise a bit of awareness for this. 
>> 
>> So let's figure out what has to be done. 
>> 
>> Norbert
>> 
>> 
>>> Am 30.05.2020 um 14:43 schrieb Stéphane Ducasse 
> 
>> stephane.ducasse@
> 
>> :
>>> 
>>> Hi all
>>> 
>>> This is the week-end and we worked super well yesterday during the
>>> sprint. Lot of good enhancements - Thanks a lot to all the participants. 
>>> I not really happy to be forced to do it on a sunny saturday but I’m
>>> doing it to clarify points.
>>> 
>>> Esteban sent me this text that was posted on Squeak-Dev (I personally do
>>> not read squeak related forums because 
>>> I have not the time and my focus is Pharo, its consortium, my team, my
>>> research and my family). 
>>> 
>>> We have to react because 
>>> - We do not really at ***all** understand this email
>>> - We did not kicked anybody from our mailing-list from ages - so ron is
>>> lying. In the past we even had discussion with ron - so we do not 
>>> really understand. May be we got problem to log on our mailing-lists. 
>>> We have no idea because we are working and not looking at such things.  
>>>  
>>> - When we migrated smalltalkhub to readonly we payed attention to make
>>> sure that private projects stay private.
>>> We did not migrated smalltalkhub for fun. We MUST do it or it will be
>>> done by our infrastructure!
>>> - Now the cryptography packages are MIT and they are public anyway. So
>>> again we do not understand anything. 
>>> 
>>> We do not get why Ron contacted us because we announced the migration
>>> publicly way in advance and we will keep 
>>> the Smalltalkhub frozen repo for at least next 5 years. 
>>> 
>>> I feel really sorry to hear such kind of email because we do not want to
>>> fight with anybody. 
>>> Our goal is to make sure that people can work with Pharo and expand their
>>> business and knowledge. 
>>> We are working hard to make sure that people can invent their future with
>>> Pharo and people that know us personally 
>>> know that we are not lying.
>>> 
>>> S
>>> 
>>> 
 Hi all,
 
 I've tried to work with the Pharo group but they keep kicking me out of
 their mailing list.  I've already mentioned this a number of times to
 the Pharo group but nobody seems to care.  
 
 BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY  BOLD BOLD BOLD
 
 I am not a lawyer but we used very good lawyers to make the squeaksource
 repository a safe place to do cryptography work.  If you are working on
 cryptography DO NOT POST your code anywhere except squeaksource. 
 Especially if you are in the USA.  The ONLY repository that is approved
 to host our cryptography code in the USA and therefore not subject to
 criminal violations is squeaksource.  It is a CRIME in the USA to move
 code and make it available on the internet for everyone to download! It
 must be hosted on squeaksoruce.com  
 

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

[Norbert Hartl]

Yes, let us coordinate what to respond. To me this doesn't even sound like Ron. 
Usually he is a rather quite and reasonable guy. Seems to be a lot of 
misunderstandings here (again).
As I was the one copying the Cryptography package to github it concerns me a 
bit. I've been remembered now about yet another strange law suit in the US and 
indeed we need to raise a bit of awareness for this. 

So let's figure out what has to be done. 

Norbert


> Am 30.05.2020 um 14:43 schrieb Stéphane Ducasse :
> 
> Hi all
> 
> This is the week-end and we worked super well yesterday during the sprint. 
> Lot of good enhancements - Thanks a lot to all the participants. 
> I not really happy to be forced to do it on a sunny saturday but I’m doing it 
> to clarify points.
> 
> Esteban sent me this text that was posted on Squeak-Dev (I personally do not 
> read squeak related forums because 
> I have not the time and my focus is Pharo, its consortium, my team, my 
> research and my family). 
> 
> We have to react because 
>   - We do not really at ***all** understand this email
>   - We did not kicked anybody from our mailing-list from ages - so ron is 
> lying. In the past we even had discussion with ron - so we do not 
>   really understand. May be we got problem to log on our mailing-lists. 
>   We have no idea because we are working and not looking at such things.  
>  
>   - When we migrated smalltalkhub to readonly we payed attention to make 
> sure that private projects stay private.
>   We did not migrated smalltalkhub for fun. We MUST do it or it will be 
> done by our infrastructure!
>   - Now the cryptography packages are MIT and they are public anyway. So 
> again we do not understand anything. 
> 
> We do not get why Ron contacted us because we announced the migration 
> publicly way in advance and we will keep 
> the Smalltalkhub frozen repo for at least next 5 years. 
> 
> I feel really sorry to hear such kind of email because we do not want to 
> fight with anybody. 
> Our goal is to make sure that people can work with Pharo and expand their 
> business and knowledge. 
> We are working hard to make sure that people can invent their future with 
> Pharo and people that know us personally 
> know that we are not lying.
> 
> S
> 
> 
>> Hi all,
>> 
>> I've tried to work with the Pharo group but they keep kicking me out of 
>> their mailing list.  I've already mentioned this a number of times to the 
>> Pharo group but nobody seems to care.  
>> 
>> BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY  BOLD BOLD BOLD
>> 
>> I am not a lawyer but we used very good lawyers to make the squeaksource 
>> repository a safe place to do cryptography work.  If you are working on 
>> cryptography DO NOT POST your code anywhere except squeaksource.  Especially 
>> if you are in the USA.  The ONLY repository that is approved to host our 
>> cryptography code in the USA and therefore not subject to criminal 
>> violations is squeaksource.  It is a CRIME in the USA to move code and make 
>> it available on the internet for everyone to download!  It must be hosted on 
>> squeaksoruce.com  or another location that is also 
>> properly registered. 
>> 
>> IF YOU COPIED CRYPTOGRAPHY CODE TO ANOTHER REPOSITORY THAT IS NOT REGISTERED 
>> I would recommend you delete it immediately.
>> 
>> END BOLD!  
>> 
>> Please feel free to post this to the Pharo mailing list because they 
>> apparently do not want to hear from me!
>> 
>> All the best,
>> 
>> Ron Teitelbaum
> 
> 
> 
> 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] [Pharo-users] [ANN] Pharo 8.0 Released!

[Norbert Hartl]

Great work and many thanks to all that supported!!

Norbert


> Am 20.01.2020 um 19:01 schrieb ducasse :
> 
> I would like to also thanks all the consortium members and the association 
> members so their continuous
> support. In addition we would like to thank SchmidtPro and Lifeware for the 
> contracts we sign to improve Pharo. 
> Pharo 80 and Pharo 90 will strongly benefit from this effort. 
> 
> S. 
> 
>> On 20 Jan 2020, at 14:23, Esteban Lorenzano > <mailto:esteba...@gmail.com>> wrote:
>> 
>> Dear World and dynamic language lovers: 
>> The time has come for Pharo 8.0 <https://pharo.org/>!
>> Pharo is a pure object-oriented programming language and a powerful 
>> environment, focused on simplicity and immediate feedback.
>> 
>> Here are the key highlights of this release:
>> 
>> The 64-bit version has become the recommended version for Windows as it was 
>> for Unix and OSX.
>> Iceberg, the git client for Pharo, reached its version 1.6.5 with several 
>> improvements and bugfixes.
>> Calypso, Pharo’s system browser has new and better refactoring integrations 
>> and AST-based suggestions for class definitions.
>> The unified foreign function interface (UnifiedFFI) has been improved with 
>> more support for literal objects, better type coercions, and more 
>> documentation.
>> Several speed improvements in code searches and compilation.
>> 
>> In addition, this version includes several previews of new tools such as the 
>> Spec2 GUI framework with native widget integration and the new DrTests test 
>> analysis tool and opens the door for the upcoming headless VMs for servers 
>> and non-blocking FFI.
>> These are just the more prominent highlights, but the details are just as 
>> important. We have closed a massive amount of issues: 2805 issues! 
>> A comprehensive changelog can be found at 
>> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo80ChangeLogs.md
>>  
>> <https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60ChangeLogs.md>).
>> While the technical improvements are significant, still the most impressive 
>> fact is that the new code that got in the main Pharo 8.0 image was 
>> contributed by more than 100 people.
>> Pharo is more than code. It is an exciting project involving energetic 
>> people. We thank all the contributors to this release:
>> Serge Stinckwich, Myroslava Romaniuk, Hilaire Fernandes, Alexandre Bergel, 
>> David Bajger, Sean DeNigris, Theodore Moen, Dayne Guerra Calle, Juraj 
>> Kubelka, Max Leske, Santiago Jose Dandois, Alistair Grant, Sabine Mana, Chia 
>> Yu, Stephan Eggermont, Milton Mamani, Pavel Krivanek, Ben Coman, Marcus 
>> Denker, Pierre Misse, Christophe Demarey, Allex Oliveira, Andreina Cota, 
>> Theo Rogliano, Clément Dutriez, Quentin Ducasse, Cyril Ferlicot, Cameron 
>> Bierwagen, Marek Niepieklo, Clotilde Toullec, Esteban Lorenzano, Vincent 
>> Blondeau, Danil Osipchuk, Eiichiro Ito, Noury Bouraqadi, Oleksandr Zaytsev, 
>> Jason Riggs, Alain Plantec, Kasper Osterbye, Leonardo Cecchi, Chi Huynh, 
>> Santiago Bragagnolo, Antonio Pierro, Pablo Tesone, Tim Mackinnon, Wesley 
>> Duerksen, Wilfred Hughes, John Brant, Evelyn Cusi Lopez, Manuel Leuenberger, 
>> Thomas Dupriez, Norbert Hartl, Torsten Bergmann, Gabriel Omar Cotelli, Carlo 
>> Teixeira, Guille Polito, Torsten Bergman, Damien Pollet, Holger Hans Peter 
>> Freyther, Julio Ripoll, Carolina Hernandez Phillips, Julien Delplanque, Hugo 
>> Lasnier, James Foster, Will Hensel, Erik Stel, Sven Van Caekenberghe, Martín 
>> Dias, Tomohiro Oda, Konrad Hinsen, Sébastien Roccaserra, Stéphane Ducasse, 
>> Denis Kudriashov, Ellis Harris, Steven Costiou
>> (If you contributed with Pharo 8.0 development in any way and we missed your 
>> name, please send us a mail and we will add you).
>> Enjoy!
>> The Pharo Team
>> Try Pharo: http://pharo.org/download <https://pharo.org/download>
>> Learn Pharo: http://pharo.org/documentation <https://pharo.org/documentation>
>> 
>> If you cannot see this, follow this link: 
>> http://pharo.org/news/pharo8.0-released 
>> <http://pharo.org/news/pharo8.0-released>

Re: [Pharo-dev] New Latest VM - Please Test

[Norbert Hartl]

thanks

> Am 19.01.2020 um 19:10 schrieb teso...@gmail.com:
> 
> You are right Norbert, sorry I miss the data.
> This is available through zeroConf.
> Doing for example:
> 
> wget -O - get.pharo.org/64/70+vmLatest | bash
> wget -O - get.pharo.org/64/80+vmLatest | bash
> 
> Cheers,
> Pablo
> 
> On Sat, Jan 18, 2020 at 7:53 AM Norbert Hartl  wrote:
>> 
>> Just a short remark. If you announce something it is good to say how to get 
>> it. What seems obvious to you is not necessarily obvious for others.
>> 
>> Norbert
>> 
>>> Am 17.01.2020 um 10:49 schrieb "teso...@gmail.com" :
>>> 
>>> Hello,
>>> I have just uploaded a new version of the VM as the latest. This
>>> version is the one to be intended for Pharo 8 release. Please feel
>>> free to test it.
>>> 
>>> Changes:
>>> 
>>> - Fix in the GC corruption error
>>> 
>>> Thanks.
>>> 
>>> --
>>> Pablo Tesone.
>>> teso...@gmail.com
>>> 
>> 
>> 
> 
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com
> 

Re: [Pharo-dev] New Latest VM - Please Test

[Norbert Hartl]

Just a short remark. If you announce something it is good to say how to get it. 
What seems obvious to you is not necessarily obvious for others. 

Norbert

> Am 17.01.2020 um 10:49 schrieb "teso...@gmail.com" :
> 
> Hello,
>  I have just uploaded a new version of the VM as the latest. This
> version is the one to be intended for Pharo 8 release. Please feel
> free to test it.
> 
> Changes:
> 
> - Fix in the GC corruption error
> 
> Thanks.
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com
> 

Re: [Pharo-dev] about signal

[Norbert Hartl]

> Am 10.01.2020 um 22:32 schrieb ducasse :
> 
> 
>> ducasse wrote
>>> It was so simple that I preferred to do it myself so like that I will look
>>> like a great Pharo contributor. 
>> 
>> :)
> :)
> 
> Sometimes I do not know if my humour is strange or not :)

It is! And you are the only one having that kind of humor ;)

Norbert
> But strange humour is better than no humour :)
> 
> Stef
> 
> PS: I read too many gary larson comics to be safe :)
> 
> 
> 

Re: [Pharo-dev] Happy new year!

[Norbert Hartl]

> Am 31.12.2019 um 11:56 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 31 Dec 2019, at 11:44, Esteban Lorenzano  wrote:
>> 
>> Hi, 
>> 
>> Just that, happy new year to everybody! :)
>> For 2020, let’s make a great Pharo 8 release and an even better Pharo 9.
> 
> +100
> 
> And I would also like to thank the whole community for their efforts to make 
> Pharo what it is today.
> 
+1000 ;)

Big thanks to the community, Inria and the consortium for making always big 
success. So I wish everyone a happy new year.
For me personally 2020 will be a year where most of my work will be dedicated 
to pharo.

Norbert 
> Sven
> 
>> Cheers!
>> Esteban
> 
> 

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

[Norbert Hartl]

Hi,

> Am 16.12.2019 um 11:41 schrieb Santiago Bragagnolo 
> :
> 
> 
> Hi everybody! 
>We are starting to discuss with norbert about letting taskit to leave my 
> incubator (my github account to go elsewhere). I have being thinking about it 
> since long time, since i would like it to allow taskit to evolve into more 
> than just my needs and wishes.
> 
>The sidequestion i am bringing today it may seem (or even be) almost 
> scholastic at this point, but i think it should have some space. 
>The question is if to move it to pharo-contributions, or if to create a 
> new pharo-processing.  
> 
I was asking this myself for a long time. Then I just started to move things to 
pharo-contributions because I could not come up with a better idea. I‘m not 
convinced that having more organizations on github will help.

>During the ESUG i came up with the idea/feeling/etc that it would be nice 
> to have a group of people interested into processing (as hobby, duty, etc) 
> for being able to push further this project and what-ever-other related 
> project.
>   During the conference i addressed norbert, tomohiro, mariano, matteo, 
> guille, pablo, noury, (people for whom processing directly or indirectly is a 
> primary concern) and i think there is even more people interested in this 
> kind of general problematic, for what i sensed specially during my esug 
> presentation. I think that to build a kind of team or group for discussing 
> and working on this subject is a step in a direction that search to solve 
> many modern daily problems that pushes us out of larger models of business 
> and interaction (cloud and derivatives). Having this points in mind i think 
> that the choice of this new github project could be a good point to start a 
> to work on this goal (as a first place of gathering). 
> 
I personally wouldn‘t do it from the start. Usually this is kind of a premature 
optimization to put groups and permissions and all of that on the table.
If it comes to groups it comes to permissions and the management of them. You 
might try to solve a problem that might not even have. But you put the burden 
of managing memberships and permissions and that prevents collaboration to some 
extent

So my golden rule to this is that if you don‘t have real good reason to add 
something like this organization, just don‘t. Wait until there is a problem. At 
that point you know what problem you have and you might have an appropriate 
idea how to solve it. This is very hard to do a priori.

But we need indeed a general approach how to handle that. Every time someone 
asks me to be added to pharo-contributions I‘m thinking about if the setup is 
ok.

Norbert

>  Still, i would like to hear other's opinion, in order to be able to deal 
> with this maybe before new year :). 
> 
>Thanks for your time and reading :) 
> 
>Santiago
> 
> 
> 
> 
> 

Re: [Pharo-dev] Building Pharo VM on Alpine Linux within Docker

[Norbert Hartl]

This is great! Do you consider to register that on dockerhub? This way a new 
docker image is built on commit/release. And everyone can use a static url to 
refer to it. I tried to create a pharo organization on dockerhub but did not 
find the time to do all of the necessary steps. If both were present referring 
to it as

pharo/alpine

would all that is needed

Norbert

> Am 03.12.2019 um 16:52 schrieb Pierce Ng :
> 
> I've put up a Dockerfile that builds the pharo.cog.spur.minheadless VM
> on Alpine Linux within Docker. This allows one to build said VM without
> having to first create an Alpine Linux installation such as through
> VirtualBox.
> 
>  https://github.com/pharo-contributions/Docker-Alpine/tree/master/vm.build
> 
> This is a multi-stage Dockerfile. The Pharo VM is built in an Alpine Linux
> 'build' container. Then the VM files are copied into a fresh Alpine Linux
> Docker image. The resulting Pharo VM Docker image is ~14 MB.
> 
> The output Docker image contains the Pharo VM only and is not runnable by
> itself. It is intended to be used as a base to build your own Docker image
> containing your application-specific Pharo image.
> 
> Tested on Ubuntu 18.04 and MacOS Mojave.
> 
> Pierce
> 
> 

Re: [Pharo-dev] Git URL issues

[Norbert Hartl]

> Am 01.11.2019 um 17:44 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 31 Oct 2019, at 12:18, Norbert Hartl  wrote:
>> 
>> 
>> 
>>> Am 31.10.2019 um 12:12 schrieb Sven Van Caekenberghe :
>>> 
>>> 
>>> 
>>>> On 25 Oct 2019, at 14:49, Sven Van Caekenberghe  wrote:
>>>> 
>>>> How do you build/deploy non-public production code using the command line ?
>>> 
>>> I just learned about the following technique:
>>> 
>>> Using SSH agent forwarding
>>> 
>>> https://developer.github.com/v3/guides/using-ssh-agent-forwarding/
>>> 
>>> This certainly makes using certificates on production servers much easier 
>>> since you do no longer have to manage or install special ones on the 
>>> deployment servers, you can just use your standard developer certificates.
>>> 
>> That is quite late :P I always use this as it also chains through all the 
>> machins you log in. We use jenkins for building our software there it does 
>> not work. We just have a deployment key for that. That is a key pair without 
>> passphrase that is registered in the git repository and installed on the 
>> jenkins server.
>> 
>> Norbert
> 
> Indeed, the SSH forwarding cannot be used for independent CI builds.
> 
> I am curious though: how do you do the initial checkout (clone) from your 
> private repository ? Using regular git command line tools or using 
> Iceberg/Metacello ?
> 
> If the latter, how do you specify your URL, exactly ?
> 
> The first case works for me too, using a gitlocal:// URL, but that is 
> cheating a bit, I feel like we should be able to do this directly in Pharo.

If checking out from private repo your problem is as deep as you reference 
private repos. My project (1) is in a private repository, it contains a 
baseline that references a project in a private repository (2) and this 
references a project in a private repo (3).

* Project (1) is checked out by jenkins. I have a deployment key pair without 
passphrase where the public key is registered in the bitbucket project and the 
private key is deployed on jenkins. 

* I try to avoid iceberg as much as possible for deployment builds because 
later I want to have an image without iceberg. And it is not reliable to use 
iceberg because metacello won't update git repos automatically and the odds are 
high that you load old content. So I load the project with the eval commandline 
handler with 

Metacello new
   repository: 'filetree://source';
   baseline …
   …

* In order to load the private projects in the the baseline of the main project 
I run a script before build that hacks the image in a way that

MCBitbucketRepository compile: 'httpsUrl
^ ''https://USER:p...@bitbucket.org/'', projectPath, ''.git'''.

MCBitbucketRepository compile: 'projectZipUrlFor: projectPath versionString: 
versionString
  ^ ''https://USER:p...@bitbucket.org/'' , projectPath , ''/get/'' , 
versionString , ''.zip'''.

MCBitbucketRepository class compile: 'projectZipUrlFor: projectPath 
versionString: versionString
  ^ ''https://USER:p...@bitbucket.org/'' , projectPath , ''/get/'' , 
versionString , ''.zip'''.

This works only because all private projects are on bitbucket and no public one.

* Project (3) I made public because I did not see how to make that work

Hope this helps. I feel this to be far too complicated. Together with the 
confusion between pharo5/pharo6/pharo7 with iceberg, tonel and iceberg and/or 
tonel support killed two weeks of my time at least. So I would welcome if there 
would be a better way to manage credentials

Norbert

Re: [Pharo-dev] Git URL issues

[Norbert Hartl]

> Am 31.10.2019 um 12:12 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 25 Oct 2019, at 14:49, Sven Van Caekenberghe  wrote:
>> 
>> How do you build/deploy non-public production code using the command line ?
> 
> I just learned about the following technique:
> 
> Using SSH agent forwarding
> 
> https://developer.github.com/v3/guides/using-ssh-agent-forwarding/
> 
> This certainly makes using certificates on production servers much easier 
> since you do no longer have to manage or install special ones on the 
> deployment servers, you can just use your standard developer certificates.
> 
That is quite late :P I always use this as it also chains through all the 
machins you log in. We use jenkins for building our software there it does not 
work. We just have a deployment key for that. That is a key pair without 
passphrase that is registered in the git repository and installed on the 
jenkins server.

Norbert

Re: [Pharo-dev] Git URL issues

[Norbert Hartl]

> Am 29.10.2019 um 17:16 schrieb Sven Van Caekenberghe :
> 
> Hi Esteban,
> 
> I tried your snippets, see comments below.
> 
>> On 29 Oct 2019, at 11:07, Esteban Lorenzano  wrote:
>> 
>> Hi Sven,
>> 
>> You are facing two different problems at the same time :)
>> 1) a problem with Metacello api. There is a mismatch between git and 
>> metacello because the apis are not equivalent (specially having iceberg in 
>> the middle). 
>> If you want to use HTTPS in metacello you have to explicit you want to use 
>> HTTPS, but you still has to use the GitHub:// identifier.
>> 
>> If you execute first: 
>> 
>> ./pharo build.image eval --save "Iceberg remoteTypeSelector: #httpsUrl”
>> 
>> Then your execution: 
>> 
>> ./pharo build.image metacello install github://svenvc/ztimestamp 
>> BaselineOfZTimestamp
>> 
>> Will work without warnings. 
> 
> Yes, this now removes the warning (not that that was a real problem).
> I do not think I understand the implications of changing the 
> remoteTypeSelector though.
> 
>> Now, you have another problem: 
>> 2) You cannot use an url as this with iceberg/metacello: 
>> https://deploy:secret@.../scm/xyz/xyz-pharo.git
>> And yes, we could do a parse of it and use it (also solving your metacello 
>> command problem), but this is not easily doable and it would take time. 
>> The usual way of doing this is not using HTTPS but distributing 
>> public/private keys (then you use the regular SSH protocol).
>> But if you still want/need to use HTTPS, then you need to provide your 
>> plaintext credentials.
>> For iceberg, your credentials are stored in your preferences directory, at 
>> credentials.fuel (so you could add them to your CI server, if you have them).
>> To add them programatically you need to do something like this: 
>> 
>> ./pharo build.image eval --save "IceCredentialStore current
>>storeCredential: (IcePlaintextCredentials new
>>username: 'esteban';
>>password: 'secret';
>>yourself)
>>forHostname: ‘github.com’"
>> 
>> Then you full script will be like this: 
>> 
>> ./pharo build.image eval --save “
>>Iceberg remoteTypeSelector: #httpsUrl”.
>>IceCredentialStore current
>>storeCredential: (IcePlaintextCredentials new
>>username: 'esteban';
>>password: 'secret';
>>yourself)
>>forHostname: 'github.com'
>> “
>> ./pharo build.image metacello install github://svenvc/ztimestamp 
>> BaselineOfZTimestamp
>> 
>> I hope this solves your problem :)
> 
> This worked as well, but since ZTimestamp is a public GitHub.com project, I 
> am not sure the authentication is really used. I tried with my GitHub.com 
> credentials (username/password) and it loaded, but when I altered the 
> password for a wrong one, it still worked ;-)
> 
> Now, the problem is: how do I access the private, password protected 
> repository of my company ?
> 
> I tried to add a host to the github:// URL but I do not have the impression 
> that this works.
> 
> Since making this more concrete involves some sensitive information, I will 
> send you a private email with the details of a test project/repository/user 
> that I made.
> 
> Sven
> 
> PS: I want to stress that for me Iceberg works really well on my local 
> development machine: I created the test project/code/baseline without 
> encountering any issue (Pharo 7).
> 
I like to second that. Working with iceberg is mostly ok. Where it is not it is 
often related more to git than to iceberg. But yes the deployment side has 
weaknesses. So my position on this that for production I want to reproducible 
load code which you cannot be sure when using iceberg with git and metacello 
(repos do not get updated automatically). This is the main reason I use https. 
Furthermore iceberg is no lightweight. So I want to have a process that I can 
use for small images as well where iceberg should be absent. Please read this 
as something to consider for future enhancement. Managing credentials is 
something that needs to be improved. In order to be able to load a dependent 
project from a private repo I recompile url methods to
inject credentials. So yes a better way is highly welcome ;)

Norbert
>> Esteban
>> 
>> On Mon, Oct 28, 2019 at 11:58 AM Sven Van Caekenberghe  wrote:
>> I am still at a loss with this issue.
>> 
>> When loading from github://svenvc/ztimestamp using Metacello (see original 
>> mail) the code in 
>> MCGitBasedNetworkRepository>>#createIcebergRepositoryWithFallbackFor:url: 
>> clearly switches to using https://github.com/svenvc/ztimestamp.git - I 
>> traced it.
>> 
>> So obviously, Pharo 7 is capable of accessing it.
>> 
>> However, starting directly with https://github.com/svenvc/ztimestamp.git I 
>> end up in a totally different place. Why ?
>> 
>> This code is so complex... 
>> 
 On 25 Oct 2019, at 14:49, Sven Van Caekenberghe  wrote:
>>> 
>>> Hi,
>>> 
>>> I asked this before, but I still have trouble with this.
>>> 
>>> What I ultimately want is what I used for years now: use 

[Pharo-dev] ESUG Videos

[Norbert Hartl]

It has been a while since ESUG took place in cologne. We are sorry for the 
delay in providing the videos of the talks but the end of summer was a busy 
time for the guy doing the videos and there is quite some material to 
post-process.

Talk videos are prepared now and we start soon to upload them to the github 
channel at [1].

Additional to the talks we ordered a short image video for the conference so 
people get an impression what the event is like. As a teaser before the 
uploading starts we want to make the image video available to you

https://zweidenker.de/en/esug-conference-2019/ 


As soon as there are videos available Marcus will drop a note about it.

Hope you like it!

the ZWEIDENKER Team

[1] https://www.youtube.com/channel/UCO-vBhaKVZf0al-ISMMPvRw 

Re: [Pharo-dev] looking for the baselineoffuel

[Norbert Hartl]

https://github.com/theseion/Fuel/tree/master/repository/BaselineOfFuel.package

Notbert

> Am 05.10.2019 um 10:05 schrieb ducasse :
> 
> Hi
> 
> I would like to depend on fuel for a project and I cannot find the baselinein 
> the image. 
> Is there one somewhere and where can I find it. 
> 
> Tx
> 
> 
> 
> 

Re: [Pharo-dev] About tweets

[Norbert Hartl]

So now I should complain why my twitter account is not in this list? ;)

All pharoers are equal ….

Norbert

> Am 05.09.2019 um 12:25 schrieb ducasse :
> 
> We are in sync. So I updated the web site to list the main pharo project
> and I put a list of other accounts with a disclaimer. 
> 
> I can do the same with the blog posts.
> 
> Stef
> 
>> On 5 Sep 2019, at 10:54, Torsten Bergmann  wrote:
>> 
>> Hi Stef,
>> 
>> I understand - but before we focus the discussion too much on the mentioned 
>> #abortionismurder let's bring #4491 into perspective:
>> 
>> 1. Important: I guess we all agree that we would like to tweet and inform as 
>> much on technical topics about Smalltalk in general and
>>   Pharo in particular and not correlate our activities to single peoples 
>> personal habits, politics, religion or beliefs.
>> 
>> 2. The aggregator that I suggested in the issue 
>> (https://twitter.com/WorldDotSt) is related to the website world.st - which 
>> is
>>   a really useful technical resource on Smalltalk, Pharo and ESUG infos 
>> already throughout the years:
>> 
>>- The forum page http://forum.world.st is summarizing various ST 
>> Mailinglists including ESUG list
>>- https://twitter.com/WorldDotSt aggregates most of the Pharo and 
>> Smalltalker Tweets in existence
>> 
>> 3. You are referring in this thread here to the following tweet: 
>> https://twitter.com/AmberSmalltalk/status/1169239145530761217
>>   which is associating @esugsmalltalk @SergeStinckwich @stephaneducasse 
>> #smalltalk for whatever reason with the hash tag #abortionismurder
>> 
>>   I understand your reaction and post - but this was done outside our 
>> boundaries by twitter user "AmberSmalltalk" - also not by the aggregator
>>   itself. And yes - this "AmberSmalltalk" owner seems to mix sometimes 
>> personal beliefs into technical infos. I share your doubts and dislike
>>   this as well.
>> 
>>   It's a problem that existed before and is a problem of tweeting and social 
>> media in general. Something that is IMHO independent from described
>>   issue #4491 - and you and Serge definitely need to sort out this 
>> #abortionismurder thing with the owner of this specific account.
>> 
>> 4. The issue #4491 mentions that currently the Pharo community page 
>> (http://www.pharo.org/community)
>> 
>>   for Twitter ONLY PROMOTES
>>   a) the offical tweet account @pharoproject
>>   b) your personal @stephaneducasse account
>>   as the ones to follow.
>> 
>>   But we have many more interesting community members tweeting on Pharo as 
>> you see on the list in the referred issue. So we should either
>>   extend the community page with either more personal accounts, just use the 
>> offical one or use an external or own aggregator
>>   including hashtags like #pharo, #pharoproject, ...
>> 
>> 
>> 5. As you might have noticed I also opened a second issue #4490 
>> (https://github.com/pharo-project/pharo/issues/4490) as for the blogs 
>> mentioned
>>   on the community page we have something similar:
>> 
>>   For Blogs WE ONLY PROMOTE on that page:
>>   a) the official pharo weekly
>>   b) my personal astares blog
>>   c) the personal blog of clement
>> 
>>   But my blog is not special either - so an aggregator of the various 
>> Smalltalks blogs (as the one suggested from planet smalltalk)
>>   made initially sense to me as it would include more blogs of members of 
>> the community and we would not have to adopt the community page all
>>   the time a new blog appears.
>> 
>>   There are nice Pharo blogs out there like https://www.samadhiweb.com/blog, 
>> http://humane-assessment.com/blog and many other.
>> 
>>   Same applies here: either we just include the offical blog that we 
>> control, a list of more blogs of the various members or an aggregator
>> 
>> 6. Yes - the community is unable to control what people write on Twitter, 
>> Blogs or other social media. Even our mailinglist "pharo-users_lists"
>>   is not free from personal habits as yesterdays disussion about "guns" 
>> showed.
>>   
>> (http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044168.html)
>> 
>>   And maybe linking to these aggregators or promoting them is not a good 
>> idea. If we take the discussion (over)serious we should then
>>   really only link to official twitter account and official pharo blog that 
>> the community can control.
>> 
>>   In such a case we need to remove my blog and your personal twitter account 
>> from the community page as you sometimes tweet about
>>   politics on your personal account too and I can potentially write on other 
>> non-technical topics on my blog as well (which I do not plan).
>> 
>> 
>> Basically we have four options:
>> a) we only link to the official twitter account 
>> (https://twitter.com/pharoproject) and blog 
>> (https://pharoweekly.wordpress.com/)
>> b) extend the list with personal twitter accounts as mentioned in issue 
>> #4491 and blogs like mentioned in #4490
>> 

Re: [Pharo-dev] About tweets

[Norbert Hartl]

Ok, there seems to be some agreeable sense. Dealing with accounts of people 
tends to collect opinions and things not related to pharo. We are not 
interested in these.
There are hashtags and mentions for things related to a topic. But a few (!) 
want to have more control. So using the @pharoproject account should be ok 
because we can like things to be includef from that account. Well at least the 
ones that have access to. 

Is this a proper summary?

Norbert

> Am 05.09.2019 um 08:48 schrieb Esteban Lorenzano :
> 
> Yes, I closed that issue. 
> 
> This is not going to happen, sorry :)
> 
> Esteban
> 
>> On 5 Sep 2019, at 08:03, ducasse  wrote:
>> 
>> Hi guys 
>> 
>> I encourage everybody to read this issue until the last conversation.
>>https://github.com/pharo-project/pharo/issues/4491
>> 
>> I have problem to promote an aggregator that can contain tweets containing 
>> #abortionismurder inside.!
>> And I have even more problem that this is in a tweet on Amber Weekly 
>> 
>> I do not know who is behind AmberSmalltalk tweets but for me this is clearly 
>> impossible to read this
>> on a tweet that Pharo supports. 
>> 
>> I also have a problem to promote an aggregator account
>> We can provide a list and people what they want. 
>> I do not like the idea of aggregation. So I vote against and I will ask the 
>> board to decide. 
>> 
>> Stef
> 
> 

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

[Norbert Hartl]

> Am 13.08.2019 um 12:28 schrieb Guillermo Polito :
> 
> Thanks for pushing this Cyril!
> This will let us move forward with Iceberg too :)

Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in 
the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter instead 
of SpMorphicGenericAdapter. Iceberg needs the former, my tool the latter. What 
is the strategy for that. For now I did a #asSpec2Adapter in my image that 
return the SpMorphic.. class.

Norbert
> 
>> El 13 ago 2019, a las 12:15, Cyril Ferlicot > > escribió:
>> 
>> On Thu, Jun 20, 2019 at 5:29 PM Cyril Ferlicot > > wrote:
>>> 
>>> Hello everyone!
>>> 
>>> This is an important update about the development of Spec.
>>> 
>>> As you might have heard, we are working on Spec to release a new
>>> version in Pharo 8. One goal is to unify all Pharo interfaces behind
>>> one GUI framework and a second goal is to allow multiple back-ends
>>> (Morphic but also GTK, Bloc, ...). To reach those goals we have been
>>> updating the current version of Spec. We see now, however, that
>>> updating Spec directly creates troubles with migration. For example,
>>> we currently have a lot of deprecation warnings in Iceberg, because we
>>> can't update it without breaking Pharo 7 compatibility.
>>> 
>>> After some discussions between the engineers working on Spec, here is
>>> our plan to improve the situation: We will copy all classes of Spec
>>> and rename them with the "Sp" prefix. (We will also ensure that every
>>> class of Spec started with the same prefix for consistency). For
>>> extensions methods, we will rename them to have a version different
>>> from Spec 1 (The spec from Pharo 7). Once done we will integrate this
>>> new version in Pharo 8. From there we will wait some weeks to let
>>> users who started to use the updated Spec change their projects to use
>>> this new Spec2. Finally, we will revert all changes that happened on
>>> Spec 1 and deprecate the packages. We hope this will make things
>>> easier for everyone.
>>> 
>>> Have a nice day!
>> 
>> Hi,
>> 
>> The revert of changes of Spec 1 is now done in Pharo 8.
>> 
>> Spec 1 is now in the same state than in Pharo 7 and Spec2 can live next to 
>> it.
>> All classes of Spec2 start with the Sp or TSp prefix.
>> 
>> Have a nice day.
>> 
>>> 
>>> --
>>> Cyril Ferlicot
>>> https://ferlicot.fr 
>> 
>> 
>> 
>> -- 
>> Cyril Ferlicot
>> https://ferlicot.fr 

Re: [Pharo-dev] [ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)

[Norbert Hartl]

This way cooler than expected. Lot of stuff already done. Great! 

Norbert

> Am 08.08.2019 um 09:53 schrieb "teso...@gmail.com" :
> 
> TL;DR;
> ==
> 
> For the anxious, you can get real headless vm and image from zero-conf.
> 
> $ wget get.pharo.org/64/80+vmHeadlessLatest | bash
> 
> Zero conf scripts remain unchanged for users.
> 
> However, if you are launching the VM by hand from the executable
> instead of the launcher scripts (pharo and pharo-ui) as in
> 
> $ ./pharoexecutable Pharo.image
> 
> the image will launch in headless mode and will not open a window.
> To launch it in headfull, you can use the --interactive argument after
> the image, which will make the image open a window using SDL2.
> 
> $ ./pharoexecutable Pharo.image --interactive
> 
> Long version
> 
> 
> Hi, this mail is the happy intermediate result of the work that us,
> the Pharo Consortium Team, has been doing in the last couple of
> months.
> Our main objective is to have a real headless implementation of Pharo
> where all the responsibility to open or not a World window (or other)
> is handled by the image.
> For doing so we have done a series of modifications in the image and
> the VM side.
> We consider this is the path that Pharo 8 and following versions
> should follow, as it will severely improve server-side and command
> line Pharo and in building custom desktop applications.
> 
> These modifications are available only in 64-bits machines (Windows,
> OSX, and Linux).
> ARM32 and 64bits headless is in the roadmap, but it is delayed because
> we have prioritized our three major platforms for this first couple of
> months.
> 
> All this work is based in Opensmalltalk-VM and Ronnie's initial work
> on headless.
> We are really grateful to all the contributors in the history of this
> nice product.
> To achieve a real headless VM we have brought modifications in the
> source tree because most of the platform code to open and manipulate
> windows is not required anymore.
> Instead, we use the SDL2 library that implements a nice layer on top
> of the OS and allows us to manage on the image side through FFI.
> 
> So this mail is now an open call for (beta?)testing.
> The sources of the current VM we are building are in the headless branch in
>  https://github.com/pharo-project/opensmalltalk-vm
> And we have set up a CI that is both building and testing the VM in
>  https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/
> 
> For the future we have a lot of ideas, that will wait for another long
> email or a beer-talk @ESUG.
> We want to hear your ideas!!
> 
> Image-Side Improvements
> ===
> 
> - The image handles the creation or not of the main world window.
> - We incorporated the idea of World renderer, where different backends
> are used to render the world.
> - We have 3 backends: VM support (compatibility with non-headless
> VMs), and OSWindow with two backends: SDL and GTK3+.
> - The modifications in the image are fully backward compatible with
> the non-headless VM and are pushed since weeks in the latest 8.0
> image.
> - We move the handling of events to the image side when using SDL and
> GTK3+, opening the door to a richer set of events and finer-grained
> control over them.
> - SDL and GTK versions are implemented using FFI calls.
> 
> VM-Side Improvements
> 
> 
> - VMMaker code migrated to Tonel thanks to Feenk and included in the
> repository of the VM.
> - Making VMMaker execute in Pharo 7 and 8.
> - Removing GPL code from the VM repository (GDB).
> 
> - Slowly adding new tests for the JIT / Slang and VMGeneration.
> - Restructuring of the source code.
> - A new simpler CMake build.
> - Generate VM code from Slang on each build.
> - A CI process to validate (including the run of the tests in Pharo
> and the ones adding to the VM).
> - Simplification of the codebase.
> 
> - Maximize the reuse of code between the platforms (preferring the
> standard versions over the platform-specific).
> - Cleaning up duplicated code.
> - All the plugins are now external plugins.
> - The VM is now a dynamic library. This is a first step towards
> embedding Pharo into other applications.
> - The main executable is a thin frontend (you can change it or
> implement your own).
> 
> - Removing unused plugins.
> - Improved crash dump. Especially the crash dump works now in Windows 64bits.
> - Dummy implementation of Security plugin (it is going away eventually).
> - Cleanup of SSL, UUID, and Socket plugin.
> 
> - Cleanup of conditional code (Still to improve).
> - Improving the types used in the functions (we have to be neat to be
> multiplatform/multi-arch).
> - Improving the lookup of modules
> - Improving the logging of the VM
> - Improving the handling of VM arguments
> 
> 
> Thanks a lot for reading so long!!
> We hope you enjoy the VM and please tell us all the problems you find!!
> 
> Pablo, Guille, and Esteban
> 

Re: [Pharo-dev] Some new bindings for native emulation stuff

[Norbert Hartl]

There is much sense in this mail, I like it. The unicorn GPL shouldn‘t be an 
issue in this usage scenario.

Well done,

Norbert

> Am 05.08.2019 um 11:48 schrieb Guillermo Polito :
> 
> 
>> El 3 ago 2019, a las 13:59, Norbert Hartl  escribió:
>> 
>> That is pretty awesome. Couldn‘t be an constraint umbrella for VMMaker. This 
>> way it would be possible to write tests that check for resulting code. Or 
>> writing tests for the JIT (does sista has something like this). Could be one 
>> step closer to a deterministic code generation, no?
> 
> Just to be fair, there are in Cog machine code simulation capabilities by 
> using Bochs for intel and gdb 7.10 for arm32.
> And there is also a starting point for testing the JIT.
> 
> However, we have seen that for this the opensmalltalk-vm contains a copy of 
> bochs and gdb source code 
>   https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/processors
> 
> And with Pablo we have thought this was a suboptimal (both regarding building 
> and licencing…), so we started to look at alternatives.
> That’s why we took a look at unicorn and llvm. Unicorn is ultimately based on 
> qemu, which is fairly mature from our point of view.
> There is not much to say about llvm :).
> 
> What is nice is that with a single set of bindings we can cover lots of 
> platforms. E.g., no need for new bindings for arm64.
> 
> Aaand, with some little adjustments here and there, we have ~85% of 114 
> existing tests passing for arm32, x86 and x86-64.
> 
> 
> Of course there are not many tests, and they are only testing the basic 
> compiler (just instructions) and not the Jitting of methods.
> But it’s a good start.
> 
> Now, also we were a bit picky about licensing:
>  - The llvm disassembler bindings are MIT.
>  - We have licensed the unicorn bindings as LGPL because Unicorn is GPL, and 
> this would allow people to use the bindings without any requirements on 
> licensing. However, any modifications to the bindings or unicorn itself 
> should be further published as LGPL or GPL.
> 
> Guille
> 
>> 
>> Norbert
>> 
>>> Am 02.08.2019 um 18:09 schrieb Guillermo Polito :
>>> 
>>> Hi everybody,
>>> 
>>> I’ve been playing around with machine code simulation this last week and 
>>> I’ve made bindings for the unicorn library and the llvm disassembler:
>>> 
>>> https://github.com/guillep/pharo-unicorn
>>> https://github.com/guillep/pharo-llvmDisassembler
>>> 
>>> Funny thing: both support lots of platforms (x86 and arm both 32 and 64 
>>> bits and more…). So out of the box we can simulate and disassemble lots of 
>>> platforms.
>>> 
>>> And in one afternoon I’ve played with them to do a native debugger with 
>>> Spec2 just for fun.
>>> Hope this evolves a bit more soon, and that it helps somebody.
>>> 
>>> Guille
>>> 
>>> 
>>> 
> 

Re: [Pharo-dev] Some new bindings for native emulation stuff

[Norbert Hartl]

That is pretty awesome. Couldn‘t be an constraint umbrella for VMMaker. This 
way it would be possible to write tests that check for resulting code. Or 
writing tests for the JIT (does sista has something like this). Could be one 
step closer to a deterministic code generation, no?

Norbert

> Am 02.08.2019 um 18:09 schrieb Guillermo Polito :
> 
> Hi everybody,
> 
> I’ve been playing around with machine code simulation this last week and I’ve 
> made bindings for the unicorn library and the llvm disassembler:
> 
> https://github.com/guillep/pharo-unicorn
> https://github.com/guillep/pharo-llvmDisassembler
> 
> Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits 
> and more…). So out of the box we can simulate and disassemble lots of 
> platforms.
> 
> And in one afternoon I’ve played with them to do a native debugger with Spec2 
> just for fun.
> Hope this evolves a bit more soon, and that it helps somebody.
> 
> Guille
> 
> 
> 

Re: [Pharo-dev] P8 + aTalent - aKind

[Norbert Hartl]

Just if you wonder where this #includesTalent: method is. You can get it from 
here

https://github.com/noha/pharo-talents/tree/api-enhancements 
<https://github.com/noha/pharo-talents/tree/api-enhancements>

Norbert


> Am 23.07.2019 um 11:24 schrieb Norbert Hartl :
> 
> I’m playing again with Talents and I want that in Pharo8 to appear so it can 
> mature. 
> 
> I want to discuss a few things I’m not clear about in order to help steering 
> the talents in the right direction.
> 
> I think Talents do not properly separate concerns. If you add a talent to an 
> object each object gets its own anonymous class with its own method 
> dictionary. To me this is two things at the same time. 
> One use case I want is „runtime traits“. It means that you can add a trait at 
> runtime to an object which acquires the functionality. But all objects of the 
> same class + talent should share the same anonymous subclass. This would be 
> possible in a performant way if I only want behavioral flexibility. It is 
> just one more class per use case.
> A second step is „object-centric behaviour“ which finally privatizes the 
> method dictionary to one object making object-centric logging/debugging/… 
> possible. This is somewhat expensive but for object centric 
> logging/debugging/… there will be only a small amount of objects being 
> extended.
> 
> With Traits and now with Talents we need to rethink parts of the reflection 
> API. We have #isKindOf: and #includesBehavior: which are not properly aligned 
> at the moment [1] and for talents it gets even wrong. I think we need a 
> definition what is a kind. What it means to include a behavior I find more 
> straight forward. 
> 
> I used a few test classes 
> 
> Object subclass: #ContainsNoTrait
>   instanceVariableNames: ''
>   classVariableNames: ''
>   package: 'Talents-Test‘
> 
> Object subclass: #ContainsOneTrait
>   uses: Doable
>   instanceVariableNames: ''
>   classVariableNames: ''
>   package: 'Talents-Test‘
> 
> Object subclass: #ContainsTwoTraits
>   uses: Doable + Doable2
>   instanceVariableNames: ''
>   classVariableNames: ''
>   package: 'Talents-Test‘
> 
> Trait named: #Doable
>uses: {}
>slots: { #status }
>package: 'Talents-Test‘
> 
> Trait named: #Doable2
>uses: {}
>slots: { #status2 }
>package: 'Talents-Test‘
> 
> Code is attached. When I create instances of each 
> 
> noTrait := ContainsNoTrait new.
> oneTrait := ContainsOneTrait new.
> twoTraits := ContainsTwoTraits new.
> 
> oneTalent := ContainsNoTrait new addTalent: Doable; yourself.
> twoTalents := ContainsNoTrait new 
>   addTalent: Doable + Doable2;
>   yourself .
> 
> and create a table of each behavior I get
> 
> 
> 
> 
> which doesn’t look quite right. My opinion is that all of the 
> #includesBehavior: calls should return true. I’m not so sure about the 
> #isKindOf: If we continue on that road the single class inheritance won’t be 
> central to all of the code but a special quality. One of the composed 
> elements can be a class with a superclass hierarchy. I don’t know if there is 
> a rationale that #includesBehavior: and #isKindOf: refer to that the same 
> thing or not.
> 
> It would be good to take the opportunity to make this a concept which gives 
> back some symmetry again.
> 
> Norbert
> 
> 
> [1] https://github.com/pharo-project/pharo/issues/3958 
> <https://github.com/pharo-project/pharo/issues/3958>
> 
> 
> 

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

[Norbert Hartl]

That‘s definetely worth a try

Norbert

> Am 10.07.2019 um 20:21 schrieb Cyril Ferlicot D. :
> 
> Hi,
> 
> After talking with Steven (in copy) we agreed on possible improvements
> around the pre debugger. I would like to share our vision and check if
> the community agrees.
> 
> Context:
> 
> The pre debugger is the window opening when an exception is signalled
> and not catched. This window currently has two views:
> - On warnings it display a text explaining the encountered problem. You
> can the proceed, abandon or debug. For example, this happens on
> Deprecations.
> - On other exceptions it display a short stack of the context in which
> the error was raised. You can abandon, open a full debugger, ...
> 
> Before, both views were managed via the same UI class. Yesterday I
> slitted this class.
> 
> Proposed change:
> 
> In our opinion, the pre debugger displaying a stack is useless. All the
> options it proposes are in the full debugger within one click reach. The
> only value we see for the pre debugger is about warnings.
> 
> Thus, we propose to remove the stack pre debugger and display directly
> the full debugger for anything else than a warning. This will save
> everyone one click each time we want to debug something. We would keep
> the textual view for warnings.
> 
> In case we do this, I wonder if we should keep the setting "Open full
> debugger". I think most users of this option are using it in order to
> not see the stack pre debugger and not to skip warnings. So, do someone
> have an opinion about keeping or removing this setting in case we remove
> the stack pre debugger?
> 
> Possible future changes:
> 
> In the future I would also like it if the opening of the pre (or full)
> debugger would be delegated to the raised exception in order to allow
> the introduction of different pre debuggers. But it's just an idea and
> not the scope of this mail. :)
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

[Pharo-dev] Pharo source code formatting guide

[Norbert Hartl]

Sometimes I wonder when I change a piece of code in pharo if there is an 
official formatting guide line. Is the formatter in calypso the incarnation of 
it or how code is supposed to be formatted in the offical image?

I just see tons of occurrences where caret immediately follows a token and such 
which I don’t like at all.

Norbert

Re: [Pharo-dev] [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[Norbert Hartl]

Great!

Can you explain what is there, what somebody can load and what to expect. And 
even more important: what not to expect?

I don’t get any of the essential details from this mail.

Norbert


> Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano :
> 
> People that assisted to Pharo Days 2019 (or that follow my twitter account) 
> already know this, but it needs to be formally announced: 
> 
> We are working on Spec 2.0, and it will provide not just the classic Morphic 
> bindings but also a new option for developers: Gtk3 bindings!
> 
> Why we want a Spec 2.0 with different backends?
> 
> There are reasons that converged to decide us to make it:
> 
> First, to provide a validated abstract Spec 2.0 that can be used with 
> different backends, preparing Pharo to be able to switch backends without 
> needing to recreate the full IDE from scratch each time (a problem we have 
> partially now in our way to deprecate Morphic).
> Second, because we receive from different sources the requirement of having 
> the possibility of developing real native-looking desktop applications. Yes, 
> in moment where people talk about the cloud, SaaS and web-applications as the 
> "next big thing" (something that is been declared since years, by the way), 
> we believe is important to provide this, for two big reasons: 
> Because there is still an important place for desktop applications market and 
> most medium-size to big business still require them.
> Because Pharo itself is a desktop application! (And we need to provide the 
> best experience possible on it).
> 
> For us, this is a fundamental step to continue improving Pharo itself, and it 
> matches also the work we are doing on going real-headless:  Pharo users will 
> be able to start the Morphic world, a Gtk application or the next backend to 
> come.
> 
> Why Gtk3?
> 
> There are some other important players in the "native widgets scene", so why 
> we choose Gtk3? 
> 
> Again, several reasons  were taken into account: 
> 
> Gtk3 is cross platform. Yes, technically is just "native" in linux, but it 
> works on Windows and macOS too. 
> It is very mature and popular.
> It is made in plain C.
> 
> Next step: tool migration
> 
> The only way to know if you have covered what is needed is actually taking 
> real-life use cases and implementing them. We have a list of tools that needs 
> to be migrated and we are starting from them: 
> 
> Old GT tools will be replaced by new Spec tools (while preserving its power).
> Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
> Pharo launcher as a standalone application is a good example of what you can 
> do with the Gtk3 bindings.
> 
> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to 
> benefit of it immediately :)
> 
> 
> A small screenshot of the new Inspector (WIP): 
> 
> 
> 
> Esteban

Re: [Pharo-dev] Roassal Animations

[Norbert Hartl]

Great! Will this be part of the minimal roassal? That could improve 
documentation quite a bit.

Norbert

> Am 18.04.2019 um 01:05 schrieb Alexandre Bergel :
> 
> Hi!
> 
> Just as a follow up, we have a UML diagram builder for Roassal3.
> 
> You can load Roassal3 using:
> Metacello new
> baseline: 'Roassal3';
> repository: 'github://ObjectProfile/Roassal3/src';
> load.
> 
> As indicated on https://github.com/ObjectProfile/Roassal3
> 
> An UML class diagram can be open using:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>| builder pharoClassesToBeVisualized |
> 
> "Zooming and position of the view can be controled using the keys:
> I O Space
> Arrows
> "
> 
> pharoClassesToBeVisualized := 
> TSAbstractLine
>  withAllSubclasses.
> 
> builder := 
> RSUMLClassBuilder
>  new.
> builder classes: pharoClassesToBeVisualized.
> 
> builder classDescriptor 
> methods: [ :cls | | methods |
> methods := cls methods sorted: [ :a :b |
> a selector < b selector ] ].
> 
> builder build.
> builder view when: 
> TSExtentChangedEvent
>  do: [ builder view zoomToFit ].
> builder open
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> We now do have a support for UML class diagrams and we can easily add new 
> features, if wanted.
> 
> 
> 
> Cheers,
> Alexandre & Milton
> 
> 
>> On Mar 27, 2019, at 3:37 PM, ducasse  wrote:
>> 
>> 
>> 
>>> On 27 Mar 2019, at 18:27, Alexandre Bergel  wrote:
>>> 
>>> 
>>> From: Alexandre Bergel 
>>> Subject: Re: [Pharo-dev] Roassal Animations
>>> Date: 27 March 2019 at 18:27:28 CET
>>> To: Pharo Development List 
>>> 
>>> 
>>> Thanks to all of you for your nice words.
>>> These posts are a teaser of what is coming. Code of each animation is part 
>>> of Roassal3. Note that we have made no official announcement, simply 
>>> because Roassal3 is still well behind Roassal2 in terms of offered 
>>> features. Actually, you cannot do much with Roassal3, beside having cool 
>>> visualization.
>>> 
>>> We will tell you more soon, once we have a UML renderer and code dependency 
>>> visualizer :-)
>>> 
>>> We are currently working on a nice distribution that can be shipped within 
>>> Pharo 8. 
>> 
>> :)
>> 
>> 
> 

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

[Norbert Hartl]

> Am 14.04.2019 um 07:49 schrieb Esteban Lorenzano :
> 
> Hi Tim, 
> 
> Is not about subprojects, is about hot fixes :)
> Pharo 7 will continue having some updates on critical bugs but it should not 
> include regular changes (like an update on Calypso). 
> In that sense, fix #2781 sneaked in and it shouldn’t, which means we still 
> need to adjust the process :P
> 
The last sentence made me very lucky.

Norbert
> Esteban
>  
> 
>> On 13 Apr 2019, at 14:50, Tim Mackinnon  wrote:
>> 
>> 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] [Pharo-users] [OT] (slightly) What makes other dialects "enjoyable" for you? (WAS: difference between double dispatch...)

[Norbert Hartl]

> Am 11.04.2019 um 21:35 schrieb Mariano Martinez Peck :
> 
> 
> 
>> On Thu, Apr 11, 2019 at 10:54 AM Norbert Hartl  wrote:
>> 
>> 
>>> Am 11.04.2019 um 15:29 schrieb Mariano Martinez Peck 
>>> :
>>> 
>>> Hi Esteban,
>>> 
>>> We talk this privately a couple of weeks ago, but I thought it was worth 
>>> writing again here. As for other IDE's being enjoyable, I can only talk 
>>> about VASmalltalk. If there is ONE thing I enjoy from it, is the stability. 
>>> May be ugly, may be too-windows, may be full of menus you don't understand 
>>> what they do, but it's really rock solid. 
>>> Pharo has been doing a LOT of progress on so many areas and its expected to 
>>> decrease a bit on stability. Unless you are Oracle and can hire 100 
>>> engineers. 
>>> So, my small recommendation to you back then was to make at least ONE 
>>> release (called LTS or whatever) were you just focus on stability and bugs. 
>>> No new features. No new framework. Just stability. Make it rock solid. Then 
>>> after that release, you can keep moving forward, but that would give 
>>> companies and really really stable Pharo to rely on. 
>>> 
>> For the provision of an LTS version we need more engineers. If there are 
>> enough companies that need a rock solid stable version then the consortium 
>> will have enough money to hire engineers for that. 
> 
> Well, either that or convince the community that that is a good thing. 
> Obviously, when you don't pay for that and things come for free it's 
> understandable you can't decide on what type of effort/results you get. And 
> for almost all of us, is much way more cool to provide a new framework, a new 
> tool, etc than bug fixing and testing. 
> 
Yes and it is ok it is that way. Peope spend their time and want to do 
something fun not the boring part. There might be projects which developed a 
culture of providing that as a value. But a general rule for open source work 
is „Either it is fun or it needs to be paid“. I cannot see anything wrong with 
that. And I if try to think about an LTS version that is not backed up by a 
company I cannot come up with one quickly.
And when we discuss this topic I want to have a clearer definition of terms. To 
me there are „stability“ and „stand-still“ mixed in the readings. Pharo 
provides quite a good stability while its moving. And that is IMHO the only way 
 it can work.
And yet there is a place for an LTS. But who uses the new version then? How can 
you ever move because people just using the „stagnated“ version? 

Norbert
>  
>> I would put a virtual machine that we can control much higher on the list of 
>> things we should have.
>> 
>> Norbert
>> 
>>> Best, 
>>>  
>>> -- 
>>> Mariano Martinez Peck
>>> Email: marianop...@gmail.com
>>> Twitter: @MartinezPeck
>>> LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/
> 
> 
> -- 
> Mariano Martinez Peck
> Email: marianop...@gmail.com
> Twitter: @MartinezPeck
> LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

Re: [Pharo-dev] [Pharo-users] [OT] (slightly) What makes other dialects "enjoyable" for you? (WAS: difference between double dispatch...)

[Norbert Hartl]

> Am 11.04.2019 um 15:29 schrieb Mariano Martinez Peck :
> 
> Hi Esteban,
> 
> We talk this privately a couple of weeks ago, but I thought it was worth 
> writing again here. As for other IDE's being enjoyable, I can only talk about 
> VASmalltalk. If there is ONE thing I enjoy from it, is the stability. May be 
> ugly, may be too-windows, may be full of menus you don't understand what they 
> do, but it's really rock solid. 
> Pharo has been doing a LOT of progress on so many areas and its expected to 
> decrease a bit on stability. Unless you are Oracle and can hire 100 
> engineers. 
> So, my small recommendation to you back then was to make at least ONE release 
> (called LTS or whatever) were you just focus on stability and bugs. No new 
> features. No new framework. Just stability. Make it rock solid. Then after 
> that release, you can keep moving forward, but that would give companies and 
> really really stable Pharo to rely on. 
> 
For the provision of an LTS version we need more engineers. If there are enough 
companies that need a rock solid stable version then the consortium will have 
enough money to hire engineers for that. 
I would put a virtual machine that we can control much higher on the list of 
things we should have.

Norbert

> Best, 
>  
> -- 
> Mariano Martinez Peck
> Email: marianop...@gmail.com
> Twitter: @MartinezPeck
> LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

Re: [Pharo-dev] how implement isAbstract?

[Norbert Hartl]

> 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] Migrating XML support to github/PharoContributions/

[Norbert Hartl]

Yes, please. Do you know https://github.com/peteruhnak/git-migration 
 ? That is a good way to preserve 
commit history in git. If you have trouble contact me please.

Norbert


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

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

[Norbert Hartl]

yeah, bright future we come!

Norbert

> Am 06.03.2019 um 13:01 schrieb Esteban Lorenzano :
> 
> 
> 
>> On 6 Mar 2019, at 12:38, Norbert Hartl > <mailto:norb...@hartl.name>> wrote:
>> 
>> How wonderful is that? How much effort it was compared to the old process?
> 
> zero.
> Bah, I needed to restart the CI because of the freetype random welcome 
> problem.
> 
> Esteban
> 
>> 
>> Norbert
>> 
>> 
>>> Am 06.03.2019 um 11:32 schrieb Esteban Lorenzano >> <mailto:esteba...@gmail.com>>:
>>> 
>>> Hi, 
>>> 
>>> I just made a bugfix release of Pharo: 
>>> 
>>> v7.0.2 <https://github.com/pharo-project/pharo/releases/tag/v7.0.2>
>>> <513630.jpeg> <https://github.com/estebanlm> estebanlm 
>>> <https://github.com/estebanlm> released this 22 hours ago
>>> 
>>> Bugfix release
>>> 
>>> #2303 <https://github.com/pharo-project/pharo/issues/2303> Deprecation 
>>> fixes in TEasilyThemed
>>> #2120 <https://github.com/pharo-project/pharo/pull/2120> Object-centric 
>>> MetaLink integration
>>> #2376 <https://github.com/pharo-project/pharo/pull/2376> Ensure subMenu is 
>>> opened (backport)
>>> #2428 <https://github.com/pharo-project/pharo/pull/2428> Add 
>>> scrollSelectionIntoView
>>> #2700 <https://github.com/pharo-project/pharo/pull/2700> Tonel test is 
>>> failing (backport)
>>> 
>>> Enjoy :)
>>> 
>>> Esteban
>> 
> 

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

[Norbert Hartl]

How wonderful is that? How much effort it was compared to the old process?

Norbert


> Am 06.03.2019 um 11:32 schrieb Esteban Lorenzano :
> 
> Hi, 
> 
> I just made a bugfix release of Pharo: 
> 
> v7.0.2 
> <513630.jpeg>  estebanlm 
>  released this 22 hours ago
> 
> Bugfix release
> 
> #2303  Deprecation fixes 
> in TEasilyThemed
> #2120  Object-centric 
> MetaLink integration
> #2376  Ensure subMenu is 
> opened (backport)
> #2428  Add 
> scrollSelectionIntoView
> #2700  Tonel test is 
> failing (backport)
> 
> Enjoy :)
> 
> Esteban

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

[Norbert Hartl]

> 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: ?


Norbert

Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write:

[Norbert Hartl]

> Am 22.02.2019 um 19:45 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 22 Feb 2019, at 19:39, Stephan Eggermont  wrote:
>> 
>> Sven Van Caekenberghe  wrote:
>> .
>>> 
>>> So I propose to remove [Stream|Collection]>>#write:
>>> 
>>> What say thou ?
>> 
>> Check the selectors used in the latest packages on squeaksource, ss3,
>> smalltalkhub and decide. 
>> 
>> Stephan
> 
> You forgot GitHub and all private company repositories in the world.
> 
hehe, indeed.

Norbert

Re: [Pharo-dev] [Ann] TelePharo and PharoThings adopted for Pharo 7

[Norbert Hartl]

> Am 17.02.2019 um 21:03 schrieb Denis Kudriashov :
> 
> Hi.
> 
> I released new versions of TelePharo (v0.3.0) and PharoThings (v0.2.3) 
> adopted for Pharo 7 changes.
> 
> PharoThings also includes new features from Alex Oliveira: 
> - Raspberry model B3
> - water alarm example
> And few models of Arduino from @gaterfy. 

Can you elaborate on this? What has an arduino model to do here?

Norbert


> 
> Best regards,
> Denis

Re: [Pharo-dev] Esteban's ChangeLog week of 4 February 2019

[Norbert Hartl]

> Am 11.02.2019 um 10:32 schrieb Guillermo Polito :
> 
> 
> 
> On Mon, Feb 11, 2019 at 9:54 AM Norbert Hartl  <mailto:norb...@hartl.name>> wrote:
> 
> 
>> Am 11.02.2019 um 09:22 schrieb Esteban Lorenzano > <mailto:esteba...@gmail.com>>:
>> 
>> 
>> 
>>> On 11 Feb 2019, at 09:20, Nicolas Cellier 
>>> >> <mailto:nicolas.cellier.aka.n...@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>> Le lun. 11 févr. 2019 à 08:45, Norbert Hartl >> <mailto:norb...@hartl.name>> a écrit :
>>> 
>>> 
>>> > Am 11.02.2019 um 08:00 schrieb esteba...@gmail.com 
>>> > <mailto:esteba...@gmail.com>:
>>> > 
>>> > Hello!
>>> > 
>>> > This is my weekly ChangeLog, from 4 February 2019 to 10 February 2019.
>>> > You can see it in a better format by going here: 
>>> > http://log.smallworks.eu/web/search?from=4/2/2019=10/2/2019 
>>> > <http://log.smallworks.eu/web/search?from=4/2/2019=10/2/2019>
>>> > 
>>> > ChangeLog
>>> > =
>>> > 
>>> > 9 February 2019:
>>> > 
>>> > 
>>> > *=== On layouts
>>> >As you know, I've been workingon layouts for Spec 2. The basic 
>>> > layouts I want to have available next week(s) are four: 
>>> > 
>>> >* +SpecBoxLayout+ : A simple way to place components horizontally or 
>>> > vertically 
>>> >* +SpecPanedLayout+ : Same as box layout, but with a resizable 
>>> > splitter (and it will allow just two... if you want more you will need to 
>>> > compose).
>>> >* +SpecGridLayout+ : To place components in a grid (x,y coordinates 
>>> > and spans)
>>> >* +SpecXYLayout+ : This could be renamed as +SpecAbsoluteLayout+ and 
>>> > it's name says all, it will allow absolute location of components 
>>> > (obviously, in relation with its parent).
>>> > 
>>> >For a second phase there will be a couple more +SpecFlowLayout+ and a 
>>> > kasowari layout (without name yet :P).
>>> > 
>>> Apple and others call it auto layout. I don‘t like that name as it isn‘t 
>>> really clear. It could be called ConstraintLayout.
>>> 
>>> +1 for  ConstraintLayout
>> 
>> Ok, Constraint will be :)
>> (But it will not arrive until half part of P8 development :P)
>> 
> No problem if you remember then ;) In the meantime you can rename XYLayout to 
> AbsoluteLayout :D
> 
> Or FixedLayout :P. Because actually it's not absolute, it's relative to its 
> parent xD.

The layout is absolute for the component it is applied to. Doesn’t matter if 
the component itself is layouted relative to something else. We don’t need to 
try hard to come up with new terms just be different to e.g. CSS 

Norbert

>  
> 
> Norbert
> 
>> Esteban
>> 
>>> 
>>> Norbert
>>> >The ones on first phase are the most important ones. In particular, we 
>>> > have detected that with 
>>> >first three (Box, Paned, Grid) we can reproduce everything we have 
>>> > currently in Pharo. The second phase 
>>> >will add possibilities for the future.
>>> > 
>>> >Anyway, I have "kind-of-working" the first three, but I have problems 
>>> > when applying layouts here and there, because
>>> >morphic time to time wants to behave differently than asked.
>>> > 
>>> >One of the problems is that for this layouts, to make them behave 
>>> > correctly (and without a lot of work from users), 
>>> >I will need to add the concept of "minimum, preferred and maximum" 
>>> > extent. Reason why I'm playing with a small
>>> >implementation of styling... which most probably will go away once I 
>>> > find the best way to handle this constraints.
>>> > 
>>> >So, this week I have nothing finished, just a pointer to my current 
>>> > work: 
>>> > [https://github.com/estebanlm/Spec/tree/dev-2.0](https://github.com/estebanlm/Spec/tree/dev-2.0)
>>> >  
>>> > <https://github.com/estebanlm/Spec/tree/dev-2.0%5D(https://github.com/estebanlm/Spec/tree/dev-2.0)>
>>> > 
>>> > 
>>> > 7 February 2019:
>>> > 
>>> > 
>>> > *Small fix-a-day: 
>>> > [https://github.com/pharo-project/pharo/pull/2452](https://github.com/pharo-project/pharo/pull/2452)
>>> >  
>>> > <https://github.com/pharo-project/pharo/pull/2452%5D(https://github.com/pharo-project/pharo/pull/2452)>
>>> > 
>>> > 
>>> > cheers! 
>>> > Esteban
>>> >
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> <http://www.cnrs.fr/>
> 
> Web: http://guillep.github.io <http://guillep.github.io/>
> Phone: +33 06 52 70 66 13

Re: [Pharo-dev] Esteban's ChangeLog week of 4 February 2019

[Norbert Hartl]

> Am 11.02.2019 um 09:22 schrieb Esteban Lorenzano :
> 
> 
> 
>> On 11 Feb 2019, at 09:20, Nicolas Cellier 
>> > <mailto:nicolas.cellier.aka.n...@gmail.com>> wrote:
>> 
>> 
>> 
>> Le lun. 11 févr. 2019 à 08:45, Norbert Hartl > <mailto:norb...@hartl.name>> a écrit :
>> 
>> 
>> > Am 11.02.2019 um 08:00 schrieb esteba...@gmail.com 
>> > <mailto:esteba...@gmail.com>:
>> > 
>> > Hello!
>> > 
>> > This is my weekly ChangeLog, from 4 February 2019 to 10 February 2019.
>> > You can see it in a better format by going here: 
>> > http://log.smallworks.eu/web/search?from=4/2/2019=10/2/2019 
>> > <http://log.smallworks.eu/web/search?from=4/2/2019=10/2/2019>
>> > 
>> > ChangeLog
>> > =
>> > 
>> > 9 February 2019:
>> > 
>> > 
>> > *=== On layouts
>> >As you know, I've been workingon layouts for Spec 2. The basic 
>> > layouts I want to have available next week(s) are four: 
>> > 
>> >* +SpecBoxLayout+ : A simple way to place components horizontally or 
>> > vertically 
>> >* +SpecPanedLayout+ : Same as box layout, but with a resizable splitter 
>> > (and it will allow just two... if you want more you will need to compose).
>> >* +SpecGridLayout+ : To place components in a grid (x,y coordinates and 
>> > spans)
>> >* +SpecXYLayout+ : This could be renamed as +SpecAbsoluteLayout+ and 
>> > it's name says all, it will allow absolute location of components 
>> > (obviously, in relation with its parent).
>> > 
>> >For a second phase there will be a couple more +SpecFlowLayout+ and a 
>> > kasowari layout (without name yet :P).
>> > 
>> Apple and others call it auto layout. I don‘t like that name as it isn‘t 
>> really clear. It could be called ConstraintLayout.
>> 
>> +1 for  ConstraintLayout
> 
> Ok, Constraint will be :)
> (But it will not arrive until half part of P8 development :P)
> 
No problem if you remember then ;) In the meantime you can rename XYLayout to 
AbsoluteLayout :D

Norbert

> Esteban
> 
>> 
>> Norbert
>> >The ones on first phase are the most important ones. In particular, we 
>> > have detected that with 
>> >first three (Box, Paned, Grid) we can reproduce everything we have 
>> > currently in Pharo. The second phase 
>> >will add possibilities for the future.
>> > 
>> >Anyway, I have "kind-of-working" the first three, but I have problems 
>> > when applying layouts here and there, because
>> >morphic time to time wants to behave differently than asked.
>> > 
>> >One of the problems is that for this layouts, to make them behave 
>> > correctly (and without a lot of work from users), 
>> >I will need to add the concept of "minimum, preferred and maximum" 
>> > extent. Reason why I'm playing with a small
>> >implementation of styling... which most probably will go away once I 
>> > find the best way to handle this constraints.
>> > 
>> >So, this week I have nothing finished, just a pointer to my current 
>> > work: 
>> > [https://github.com/estebanlm/Spec/tree/dev-2.0](https://github.com/estebanlm/Spec/tree/dev-2.0)
>> >  
>> > <https://github.com/estebanlm/Spec/tree/dev-2.0%5D(https://github.com/estebanlm/Spec/tree/dev-2.0)>
>> > 
>> > 
>> > 7 February 2019:
>> > 
>> > 
>> > *Small fix-a-day: 
>> > [https://github.com/pharo-project/pharo/pull/2452](https://github.com/pharo-project/pharo/pull/2452)
>> >  
>> > <https://github.com/pharo-project/pharo/pull/2452%5D(https://github.com/pharo-project/pharo/pull/2452)>
>> > 
>> > 
>> > cheers! 
>> > Esteban
>> >

Re: [Pharo-dev] Esteban's ChangeLog week of 4 February 2019

[Norbert Hartl]

> Am 11.02.2019 um 08:00 schrieb esteba...@gmail.com:
> 
> Hello!
> 
> This is my weekly ChangeLog, from 4 February 2019 to 10 February 2019.
> You can see it in a better format by going here: 
> http://log.smallworks.eu/web/search?from=4/2/2019=10/2/2019
> 
> ChangeLog
> =
> 
> 9 February 2019:
> 
> 
> *=== On layouts
>As you know, I've been workingon layouts for Spec 2. The basic layouts 
> I want to have available next week(s) are four: 
> 
>* +SpecBoxLayout+ : A simple way to place components horizontally or 
> vertically 
>* +SpecPanedLayout+ : Same as box layout, but with a resizable splitter 
> (and it will allow just two... if you want more you will need to compose).
>* +SpecGridLayout+ : To place components in a grid (x,y coordinates and 
> spans)
>* +SpecXYLayout+ : This could be renamed as +SpecAbsoluteLayout+ and it's 
> name says all, it will allow absolute location of components (obviously, in 
> relation with its parent).
> 
>For a second phase there will be a couple more +SpecFlowLayout+ and a 
> kasowari layout (without name yet :P).
> 
Apple and others call it auto layout. I don‘t like that name as it isn‘t really 
clear. It could be called ConstraintLayout.

Norbert
>The ones on first phase are the most important ones. In particular, we 
> have detected that with 
>first three (Box, Paned, Grid) we can reproduce everything we have 
> currently in Pharo. The second phase 
>will add possibilities for the future.
> 
>Anyway, I have "kind-of-working" the first three, but I have problems when 
> applying layouts here and there, because
>morphic time to time wants to behave differently than asked.
> 
>One of the problems is that for this layouts, to make them behave 
> correctly (and without a lot of work from users), 
>I will need to add the concept of "minimum, preferred and maximum" extent. 
> Reason why I'm playing with a small
>implementation of styling... which most probably will go away once I find 
> the best way to handle this constraints.
> 
>So, this week I have nothing finished, just a pointer to my current work: 
> [https://github.com/estebanlm/Spec/tree/dev-2.0](https://github.com/estebanlm/Spec/tree/dev-2.0)
> 
> 
> 7 February 2019:
> 
> 
> *Small fix-a-day: 
> [https://github.com/pharo-project/pharo/pull/2452](https://github.com/pharo-project/pharo/pull/2452)
> 
> 
> cheers! 
> Esteban
> 

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Norbert Hartl]

> 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] Roadmap for Pharo 8.0

[Norbert Hartl]

> Am 08.02.2019 um 14:04 schrieb Alexandre Bergel via Pharo-dev 
> :
> 
> 
> Von: Alexandre Bergel 
> Betreff: Aw: [Pharo-dev] Roadmap for Pharo 8.0
> Datum: 8. Februar 2019 um 14:04:24 MEZ
> An: Pharo Development List 
> 
> 
> 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?
> 
That would be nice for the delivered image. With a revamped Connectors 
implementation (does anyone remember?) I would only wish a format for 
integrating this into pillar that would make documentation super awesome.

Norbert

> Cheers,
> Alexandre
> 
>> On Feb 7, 2019, at 12:08 PM, Esteban Lorenzano  wrote:
>> 
>> Hi list, 
>> 
>> We started Pharo 8.0 development and we wanted to share (and discuss, if 
>> needed) what is our current Roadmap for Pharo 8.0.
>> As you can see, Windows is getting some love, and also UI.
>> Anyway, here it is: 
>> 
>> Image
>> ===
>> 1) Missing parts for headless VM to work (explained a bit later)
>> 2) We need to improve Epicea speed. And in general, source access speed. We 
>> want to remove the old changes file (since Epicea already does that works 
>> and a lot more).
>> 3) Improve Refactors
>> 4) Improve Calypso
>> 5) Introduce Spec2 (our re-work on this framework).
>>  - We also want to migrate our tools to it (Inspector, Debugger, Spotter 
>> and Calypso are the remaining parts). We will see how much of this migration 
>> can be done.
>> 
>> VM/Low-level side
>> ===
>> 1) headless vm
>> We want to have a real headless VM and make it our default VM.
>> To it, most of the work vm-side is already made by Ronie, but there are 
>> missing parts: 
>> - a build on windows
>> - image side capabilities: we use SDL2 to start the world, and it mostly 
>> works... but not completely.
>> 
>> One cool thing of this is that we will -finally- be able to clean the event 
>> handling, which is ugly (and works bad).
>> 
>> 2) Windows several missing/non working parts: 
>> - file primitives are slow. This is because they rely in old APIs and we 
>> need to put them in "state of the art".
>> - libgit2 does not processes long paths. We workarounded the problem with 
>> tonel, but at a point we need to take care about this. Real problem with 
>> this is we need to contribute the solution to libgit2, but this is also good 
>> Open Source policy (contributing back).
>> - OSSubprocess in windows. We believe we need to extend OSSubprocess (our 
>> solution to communicate with system) to windows. And we believe is possible 
>> ;)
>> 
>> 3) ThreadedFFI. 
>> It is already too much time since we have this in agenda. Is time to make it 
>> real.
>> 
>> 4) memory policies. 
>> Tweaking the VM to enhance its memory usage is possible, but hard. We want 
>> to adopt an scheme of "memory policies" that will allow users to pick what 
>> they need.
>> 
>> Process
>> ===
>> 1) We will add multiple source directories to Iceberg. This is needed to 
>> allow us to put all Pharo sub-projects into an unique project without 
>> breaking modularisations.
>> 
>> Others
>> ===
>> 1) Launcher
>>  - Launcher us getting a new UI
>>  - Tests
>>  - It needs to be more solid (in part, that's the reason why we want 
>> OSSubprocess in windows).
>> 2) Cargo
>>  - We need to revisit cargo (a new dependency manager) and at a point 
>> decide if it will fly or not :)
>> 
>> Nice to have (most probably not this version, but in our TODO) :
>> - embedded VM
>> - event driven VM
>> - what happens if we split VM into main thread and vm thread?
>> 
>> 
> 
> 
> 
> 

Re: [Pharo-dev] [ANN] Pharo open documentation

[Norbert Hartl]

Very good initiative! Did you talk about the catalog, too? This list somehow 
mirrors the catalog. And as it is done in markdown it does not easily work as a 
parsable document, does it?

Norbert


> Am 30.01.2019 um 15:00 schrieb Cyril Ferlicot :
> 
> Hi everyone!
> 
> With some other members of the community we are proud to announce a
> new effort on Pharo documentation.
> 
> We launched an organization pharo-open-documentation which is a
> user-maintained documentation related to Pharo environment, language,
> and libraries.
> 
> Currently it has three main projects:
> - pharo-wiki : Wiki related to the Pharo programming language and environment.
> - awesome-pharo : A collection of awesome Pharo libraries, tools,
> frameworks and software. We want to make this project a reference in
> https://github.com/sindresorhus/awesome
> - awesome-pharo-ml : List of projects, books, booklets, papers, and
> applications related to machine learning, AI, data science in Pharo.
> 
> Contributions are welcomed!
> 
> If you own a cool project in Pharo others could use in their own
> projects, send us a PR to awesome-pharo!
> If you have knowledge on Pharo or projects of Pharo, we would be glad
> if you could contribute to the pharo-wiki! Don't forget to read the
> contribution guidelines. ;)
> 
> We opened a Twitter to announce new entries on the pharo-wiki.
> 
> https://twitter.com/PharoOpen
> 
> Have a nice day!
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

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

[Norbert Hartl]

> Am 30.01.2019 um 20:23 schrieb ducasse :
> 
> it means this is a call for fork :)
> 
No! A fork from something not github to github is contraproductive. 

Norbert
>>> On 30 Jan 2019, at 16:58, Norbert Hartl  wrote:
>>> 
>>> 
>>> 
>>> Am 30.01.2019 um 16:13 schrieb Sven Van Caekenberghe :
>>> 
>>> 
>>> 
>>>> On 3 Oct 2018, at 07:43, monty  wrote:
>>>> 
>>>> I am the principal maintainer of those projects, but any PharoExtras dev 
>>>> can contribute. And the blog below (which I plan on updating) provides 
>>>> additional information on them.
>>> 
>>> Has there been any progress in this area ?
>>> 
>>> It would be really great if this important project moved to GitHub.
>>> 
>> +100
>> 
>> Norbert
> 

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

[Norbert Hartl]

> Am 30.01.2019 um 16:13 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 3 Oct 2018, at 07:43, monty  wrote:
>> 
>> I am the principal maintainer of those projects, but any PharoExtras dev can 
>> contribute. And the blog below (which I plan on updating) provides 
>> additional information on them.
> 
> Has there been any progress in this area ?
> 
> It would be really great if this important project moved to GitHub.
> 
+100

Norbert

Re: [Pharo-dev] [ANN] SmalltalkCI now supports Pharo 8

[Norbert Hartl]

> Am 23.01.2019 um 08:20 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 23 Jan 2019, at 01:13, Ben Coman  wrote:
>> 
>> Only in the past week I became aware of that SmalltalkCI was integrated with 
>> Travis...
>> https://docs.travis-ci.com/user/languages/smalltalk
>> 
> 
> Shame on you ;-)
> 
> Seriously: I have it on all my projects, it works great

full ack

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

[Norbert Hartl]

> Am 23.01.2019 um 04:13 schrieb Sean P. DeNigris :
> 
> EstebanLM wrote
>> https://news.ycombinator.com/item?id=18968116
> 
> Wow! 13 hours without any hardcore flame wars. We are improving ;-)
> 
> 
> EstebanLM wrote
>> https://www.reddit.com/r/programming/comments/aimwlh/pharo_70_released/ 
> 
> Ew, not as warm and fuzzy here ha ha

Well, I‘m always amazed how negative people are. But on the other hand there is 
some truth in there. If we don‘t focus on how people encounter pharo the first 
time it is not getting easier. 
And we should professionalize our environment. That there was a gateway timeout 
when people tried to access it is just not good. I don‘t mind if it is a 
ridiculous setting in Inria or if it is a prototypical, not maintained CMS that 
is the root of trouble. 

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

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

[Norbert Hartl]

Congratulations to you all! It has been a hard piece of work which was 
postponed 9 months. But the changes to collaboration process, build process, 64 
bit maturing and huge list of things  was worth it. Hopefully the next version 
is less huge.

Happy to be able to take part!!!

Norbert

> Am 22.01.2019 um 14:36 schrieb Esteban Lorenzano :
> 
> Pharo 7.0 released!
> ===
> 
> Dear World and dynamic language lovers: 
> 
> The time has come for Pharo 7.0!
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> 
> 
> 
> 
> This is our most significant release yet. Here are the key highlights of this 
> release:
> 
>   • Pharo is now provided in 64-bit version in Linux and OSX and brings 
> even better performance and stability. The 64-bit version is now recommended 
> for Linux and Mac, and is provided as technical preview for Windows.
>   • Pharo comes with a new version of the PharoLauncher 
> (https://pharo.org/download): THE tool to manage your distributions (access 
> to regular versions, jenkins builds, and older versions). 
>   • Pharo build has a fully new build process that supports its full 
> bootstrap from sources. This will enable the production to specific (micro) 
> images. 
>   • Iceberg, the git client for Pharo has been significantly improved, 
> and is the default CMS.
>   • Calypso, the angular stone of PharoThings, is the new system Pharo 
> browser. It replaces Nautilus and brings better remote working and more 
> advanced browsing capabilities. 
>   • IoT is now an important part of Pharo. Installing PharoThings 
> (https://github.com/pharo-iot/PharoThings) provides an impressive amount of 
> tools to develop applications in small devices.
>   • The unified foreign function interface (UnifiedFFI) for interfacing 
> with the outside world is significantly improved to work properly on Windows 
> 64-bit. 
> 
> Pharo 70’s new infrastructure and process set the stage for a new generation 
> of version. 
> The visibility of GitHub combined with the powerful tools that have been 
> validated with more than one year of beta testing is massively pay off.
> 
> These are just the more prominent highlights, but the details are just as 
> important. 
> 
> We have closed a massive amount of issues: 2142 issues! (A comprehensive 
> changelog can be found at: 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo70ChangeLogs.md).
> 
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 7.0 image was 
> contributed by more than 75 people.
> 
> Pharo is more than code. It is an exciting project involving energetic 
> people. We thank all the contributors of this release:
> 
> Gabriel Omar Cotelli, Gustavo Santos, Marcus Denker, Torsten Bergmann, 
> Esteban Lorenzano, Bernardo Ezequiel Contreras, Guille Polito, Pablo Tesone, 
> Yoan Geran, Stéphane Ducasse, Cyril Ferlicot, Vincent Blondeau, Denis 
> Kudriashov, Julien Delplanque, Tim Mackinnon, Max Leske, Andrew P. Black, 
> Tomohiro Oda, Clément Béra, Ben Coman, Eric Gade, Yuriy Tymchuk, Nicolas 
> Cellier, Biyalou-Sama Asbath, Myroslava, Sean DeNigris, Juraj Kubelka, Noury 
> Bouraqadi, Holger Freyther, Geoff Reedy, Norbert Hartl, Paul DeBruicker, 
> Alain Plantec, Martín Dias, Peter Uhnak, Tomohiro Oda, Benoît Verhaeghe, 
> Santiago Bragagnolo, Wouter van Zuilen, Bernhard Pieber, Damien Pollet, Geoff 
> Hill, Hans-Martin Mosner, Ronie Salgado, Philippe Back, Aliaksei Syrel, Dayne 
> Guerra, Rafael Luque, Serge Stinckwich, Vincent Aranega, Hernán Morales 
> Durand, Petr Fischer, Rajula Vineet Reddy, Alexandre Bergel, Esteban A. 
> Maringolo, Jan Blizničenko, Johan Brichau, Luc Fabresse, Quentin Ducasse, 
> Sébastien Roccaserra, Stephan Eggermont, Sven Van Caekenberghe, Takano 
> Mitsuhiro, Pavel Krivanek, Allex Oliveira, Christophe Demarey, Lionel Akue, 
> Nicolai Hess, Martin McClure, Alistair Grant, Pierre Tsapliayev, Milton 
> Mamani, Matteo Marra, Thomas Dupriez, Asbathou Biyalou-Sama.
> (If you contributed with Pharo 7.0 development in any way and we missed your 
> name, please send us a mail and we will add you).
> 
> Enjoy!
> The Pharo Team
> 
> Try Pharo: http://pharo.org/download
> Learn Pharo: http://pharo.org/documentation
> 

Re: [Pharo-dev] Bad baseline practices

[Norbert Hartl]

> Am 16.01.2019 um 09:42 schrieb Stephan Eggermont :
> 
> Cyril Ferlicot 
> wrote:
>> On Tue, Jan 15, 2019 at 6:03 PM Stephan Eggermont via Pharo-dev
>>  wrote:
>>> 
>>> 
>>> 
>>> I’m not sure why, but I’ve noticed baselines being changed to refer to
>>> patch versions for releases. Why are the old configuration problems
>>> repeated?
>> 
>> Which project are you talking about?
> 
> In a plain Pharo 7 image
> 
> BaselineOfCalypso
> BaselineOfCommander
> BaselineOfSystemCommands
> 
> Stephan
> 
Wasn’t the problem that the wildcard notation is likely to hit the github API 
request limit?

Norbert

Re: [Pharo-dev] external#senders (was Re: DebugSession>>activePC:)

[Norbert Hartl]

> Am 11.01.2019 um 11:33 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 11 Jan 2019, at 08:45, Esteban Lorenzano  wrote:
>> 
>> You know? since we are sharing frustrations, I have to say: we already had 
>> that process (which was the old pharo-vm project). In that project, for each 
>> version of vmmaker we were loading it, generating a vm and running pharo 
>> tests there (since there are no vm-specific tests, this was working at least 
>> to test things were not broken). 
>> And… we were told this was not good and that we needed to submit to the 
>> canonical way of building the vm, which we did to not split more the 
>> community. 
>> 
>> In the process we lost all our validation process. 
>> 
>> Now we are told that we remove things without caring. 
>> But we care, and we spent a lot of time and effort putting in place 
>> mechanisms to allow things to continue moving.
>> And then we needed to throw it away.
>> 
>> Maybe now we have a new attempt and possibility of improving, but honestly I 
>> already spent one year of the work this community pays me to do to improve 
>> things and then it was wasted work. 
>> I do not thing I want to spend another “sabatical” year like that.
>> 
>> Esteban
>> 
>> Ps: I’m sorry for the frustration rant, but when I see this things emerge I 
>> become very-very sad.
> 
> One can only image, dream, of a world where VM development decided years ago 
> to step into the future with a better process, better code management, modern 
> tools, actual CI, tests, open process for real, welcoming more contributors, 
> catering for its largest user base.
> We live in an ever changing world, resisting change is not the solution.
> 
> Open source is about embracing and nurturing community, and yes that is 
> sometimes messy, but totally worth it.
> 
Amen  
> 

Re: [Pharo-dev] [Pharo-users] [Ann] TaskIt v1.0

[Norbert Hartl]

Hi Santiago,


> Am 29.11.2018 um 17:48 schrieb Santiago Bragagnolo 
> :
> 
> Hi Norbert! 
> 
> We don't have yet implemented any nor all combinations. I will add it to the 
> list of things to do for next release. Looks like a simple and useful thing 
> to have. (Or if you have already something I wouldn't mind to integrate it)
> 
I don’t have it now but I think when we change to TaskIt we will make them and 
we could provide it then.

Norbert

> 
> 
> Thanks. 
> Santiago
> 
> 
> El jue., 29 de nov. de 2018 17:36, Norbert Hartl via Pharo-users 
> mailto:pharo-us...@lists.pharo.org>> escribió:
> Great, thanks! 
> 
> Does TaskIt include implementations for combining futures such as the ALL and 
> the ANY futures which resolve either when all or one future resolves? From 
> the documentation it looks that rather not.
> 
> Norbert
> 
> 
>> Am 29.11.2018 um 15:29 schrieb Santiago Bragagnolo 
>> mailto:santiagobragagn...@gmail.com>>:
>> 
>> Hi everybody :). 
>> 
>> I am happy to announce TaskIt v1.0.
>> 
>> In this version we add some new features, passed over the red tests and 
>> clean up some dead code. And did a pass in the documentation  
>> 
>> A bit from the DOC 
>> Downloading
>> 
>> Current stable version of taskit can be downloaded using metacello as 
>> follows:
>> 
>> Metacello new
>>   baseline: 'TaskIt';
>>   repository: 'github://sbragagnolo/taskit <>';
>>   load.
>> If you want a specific release such as v1.0, you can load the associated tag 
>> as follows
>> 
>> Metacello new
>>   baseline: 'TaskIt';
>>   repository: 'github://sbragagnolo/taskit:v1.0 <>';
>>   load.
>> Otherwise, if you want the latest development version, take a look at the 
>> development branchs and load the latest:
>> 
>> Metacello new
>>   baseline: 'TaskIt';
>>   repository: 'github://sbragagnolo/taskit:dev-1.1 <>';
>>   load.
>>  
>> <https://github.com/sbragagnolo/taskit/blob/master/README.md#major-features>Major
>>  Features
>> 
>> Actors (ActIt)
>> Configuration Profiles
>> Service
>> 
>> Check specially the configuration profiles. The default profile usage is 
>> #development, which sets up the environment for debugging exceptions in a 
>> process.
>> 
>> I want to thank a lot to the contributors, Guillermo Polito Max Leske and  
>> Daniel Sasu.
>> I want as well to thanks the users, specially to those that bring me 
>> feedback (blames and ideas) in person (Esteban, Pablo)  or through the 
>> different channels (Holger Freyther, Juraj Kubelka, Philippe Back).
>> 
>> 
>> I want also to apologise the delay of my responses on the issue board :) 
>> (Really, sorry). I am constantly using TaskIt in other projects, but much 
>> times I cannot do it my priority. 
>> 
>> 
>> thanks a lot, 
>> 
>> Santiago Bragagnolo. 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

Re: [Pharo-dev] [Ann] TaskIt v1.0

[Norbert Hartl]

Great, thanks! 

Does TaskIt include implementations for combining futures such as the ALL and 
the ANY futures which resolve either when all or one future resolves? From the 
documentation it looks that rather not.

Norbert


> Am 29.11.2018 um 15:29 schrieb Santiago Bragagnolo 
> :
> 
> Hi everybody :). 
> 
> I am happy to announce TaskIt v1.0.
> 
> In this version we add some new features, passed over the red tests and clean 
> up some dead code. And did a pass in the documentation  
> 
> A bit from the DOC 
> Downloading
> 
> Current stable version of taskit can be downloaded using metacello as follows:
> 
> Metacello new
>   baseline: 'TaskIt';
>   repository: 'github://sbragagnolo/taskit';
>   load.
> If you want a specific release such as v1.0, you can load the associated tag 
> as follows
> 
> Metacello new
>   baseline: 'TaskIt';
>   repository: 'github://sbragagnolo/taskit:v1.0';
>   load.
> Otherwise, if you want the latest development version, take a look at the 
> development branchs and load the latest:
> 
> Metacello new
>   baseline: 'TaskIt';
>   repository: 'github://sbragagnolo/taskit:dev-1.1';
>   load.
>  
> Major
>  Features
> 
> Actors (ActIt)
> Configuration Profiles
> Service
> 
> Check specially the configuration profiles. The default profile usage is 
> #development, which sets up the environment for debugging exceptions in a 
> process.
> 
> I want to thank a lot to the contributors, Guillermo Polito Max Leske and  
> Daniel Sasu.
> I want as well to thanks the users, specially to those that bring me feedback 
> (blames and ideas) in person (Esteban, Pablo)  or through the different 
> channels (Holger Freyther, Juraj Kubelka, Philippe Back).
> 
> 
> I want also to apologise the delay of my responses on the issue board :) 
> (Really, sorry). I am constantly using TaskIt in other projects, but much 
> times I cannot do it my priority. 
> 
> 
> thanks a lot, 
> 
> Santiago Bragagnolo. 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: [Pharo-dev] Version control of Playground scripts

[Norbert Hartl]

> Am 29.11.2018 um 11:15 schrieb Christopher Fuhrman 
> :
> 
> 
> 
> On Wed, 28 Nov 2018 at 10:23, Norbert Hartl  <mailto:norb...@hartl.name>> wrote:
>> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman 
>> mailto:christopher.fuhr...@inria.fr>>:
>> 
>> Knowing Playground files are saved on local disk, I got to thinking... What 
>> would be the risk(s) of using git outside Pharo, on the Playground files' 
>> directory? Has anyone tried that before?
>> 
> It is not a problem. I use this every day. Meaning all my repos have a 
> scripts folder where I put my helper scripts. In the image I open this with
> 
> ’scripts’ asFileReference inspect
> 
> This is great. Thanks! 
>  
> so you get kind of a file browser of all the scripts. If you call the files 
> with an extension of .st you get syntax highlighting. If you change a script 
> with cmd-s the file gets modified and you can check into git. The problem 
> here is that if you have modifications in the image you should commit that 
> first because if you do on the scripts folder first the image working copy is 
> detached and there is no easy way to commit your in-image changes. You would 
> have to do a branch which is cumbersome. 
> 
> I'm a bit lost here: 
> 
> 1. Are you using Iceberg within Pharo (when you speak of "committing that 
> first"), or are you using only git outside of Pharo? Also, I think it's 
> possible to use a git repo with monticello? 
> 2. I'm not an advanced git user, so how do I set up my Pharo image directory 
> to work with the 'scripts' folder (again, with Iceberg if possible, as it 
> seems to be the most user-friendly)?
> 
> Thanks for your patience with my beginner questions.  
> 
You are welcome. We like to share with people that want to know ;)

The problem in understanding is a hard one. Using git means there are two 
repositories, one online in the git server and the working copy you checked out 
locally. When using pharo there is a third one and that is the working copy 
within your image. Having these two there is a number of conflicts possible. As 
pharo does not manage external resources like these scripts you can have 
trouble here. When you go to the command line and commit the script and you go 
back to pharo it tells you that you are in detached state. It means that the 
git index is not the same as it was when you loaded stuff via pharo. That is 
why I was saying that a good flow would first commit the pharo changes and then 
the ones on the command line. 

Hope this helps,

Norbert

> Cheers,
> 
> Christopher
>  
> With the scripts in place I have developed a workflow of creating new images. 
> I have a script that downloads a new image and renames it for the project. 
> And if it finds a script 
> 
> scripts/prepare-image.st <http://prepare-image.st/>
> 
> it gets executed. This contains metacello commands to load the project code 
> and settings I need in a new image. This way it is super easy to create a new 
> image for your work. And as all the scripts you use are on the filesystem 
> there is usually no state in the image that needs to be transferred to a new 
> image.
> 
> Norbert
> 
> 

Re: [Pharo-dev] Excel export with Tabular

[Norbert Hartl]

Is there any progress on this? Can you tell the S3 url you are using? 

Do you need help to put it on github?

Norbert


> Am 12.11.2018 um 22:41 schrieb Hans-Martin Mosner :
> 
> I put it on ss3 because I'm not yet familiar with the way Pharo uses github. 
> Will look into it later.
> 
> I'm unsure how git repositories are used in the Pharo context. Do you use 
> them just like you use git normally (i.e. I
> use my git repository, you use yours and send me pull requests etc...). Are 
> there any catalog systems that allow one to
> register and find projects? This whole issue has always been a bit confusing 
> in the Squeak/Pharo world due to the number
> of different options.
> 
> Cheers,
> Hans-Martin
> 
> Am 11. November 2018 10:50:40 nachm. schrieb Sven Van Caekenberghe 
> :
> 
>> Hi Hans-Martin,
>> 
>> This is great. I use Tabular too and was missing active 
>> development/maintenance. It would be very good to see this
>> project move forward. It is quite important/useful in enterprise contexts.
>> 
>> Thx,
>> 
>> Sven
>> 
>> PS: where did you commit the changes ? any chance of moving it to GitHub 
>> (too) ?
>> 
>>> On 11 Nov 2018, at 22:16, Hans-Martin  wrote:
>>> 
>>> Hello folks,
>>> I have a need for creating excel files with more than 3 worksheets, so I
>>> took the Tabular code and beefed up the exporter a little. It does handle
>>> more worksheets now, uses XMLWriter to create all the ZIP members, and is
>>> properly named now (the class was called TabularXSLXExport, note swapped S
>>> and L).
>>> Some tests have been added, there are a number of items that I plan to to as
>>> time allows:
>>> - Add (possibly limited) support for styles and formulas which I
>>> specifically need for the project I'm working on so I could write files with
>>> the desired layout and functionality.
>>> - Add support for reading more aspects of XLSX files, preferrably as much as
>>> needed to be able to read and write most files without loss.
>>> - Add rendering, maybe at the basic morphic level, maybe using something
>>> else as I'm not really up-to-date regarding the developments in Pharo.
>>> - Add formula evaluation.
>>> - Add editing capabilites to have a fully functional spreadsheet (really far
>>> off).
>>> 
>>> Cheers,
>>> Hans-Martin
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>> 
> 
> 
> 
> 

Re: [Pharo-dev] Version control of Playground scripts

[Norbert Hartl]

> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman 
> :
> 
> Hello,
> 
> In Pharo 6.1 I have got Iceberg working and love the interface to GitHub. 
> Thanks to the Rmod folks for all the patient answers to my newbie questions. 
> 
> However, most of my development remains in playground scripts, and as far I 
> understand, it's not possible to put them under version control with Iceberg.
> 
> My scripts *could* be turned into classes eventually (some already have been 
> and are under Iceberg). But it feels frustrating to rush it, just to get the 
> versioning.
> 
> I know how to save Playground files to the web, which is useful, but of 
> course not version control per se.
> 
> Knowing Playground files are saved on local disk, I got to thinking... What 
> would be the risk(s) of using git outside Pharo, on the Playground files' 
> directory? Has anyone tried that before?
> 
It is not a problem. I use this every day. Meaning all my repos have a scripts 
folder where I put my helper scripts. In the image I open this with

’scripts’ asFileReference inspect

so you get kind of a file browser of all the scripts. If you call the files 
with an extension of .st you get syntax highlighting. If you change a script 
with cmd-s the file gets modified and you can check into git. The problem here 
is that if you have modifications in the image you should commit that first 
because if you do on the scripts folder first the image working copy is 
detached and there is no easy way to commit your in-image changes. You would 
have to do a branch which is cumbersome. 

With the scripts in place I have developed a workflow of creating new images. I 
have a script that downloads a new image and renames it for the project. And if 
it finds a script 

scripts/prepare-image.st 

it gets executed. This contains metacello commands to load the project code and 
settings I need in a new image. This way it is super easy to create a new image 
for your work. And as all the scripts you use are on the filesystem there is 
usually no state in the image that needs to be transferred to a new image.

Norbert

Re: [Pharo-dev] Zinc HTTP Components version 3.0.1

[Norbert Hartl]

Great That removes a decent disruption we had. Thank you very much!

Norbert

> Am 22.11.2018 um 21:55 schrieb Sven Van Caekenberghe :
> 
> I finally merged and synced all Zinc HTTP Components repos and did a full 
> release on Pharo versions 3 to 7.
> 
>  https://github.com/svenvc/zinc/releases/tag/v3.0.1
> 
> Main README was updated
> 
>  https://github.com/svenvc/zinc
> 
> Green build for Pharo 7 RC1 (linux 64-bit) using BaselineOfZincHTTPComponents
> 
>  https://travis-ci.org/svenvc/zinc
> 
> Green builds for Pharo 3, 4, 5 and 6 using ConfigurationOfZincHTTPComponents 
> (#stable 3.0.1)
> 
>  https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/
> 
> If there are any problems or issues, don't hesitate to ask.
> 
> Sven
> 
> 
> 
> 

Re: [Pharo-dev] WELL512 PRNG

[Norbert Hartl]

I was about to say let‘s add this to the Cryptography package 

> Am 09.11.2018 um 15:34 schrieb Serge Stinckwich :
> 
> Can you contribute your code to PolyMath: 
> https://github.com/PolyMathOrg/PolyMath
> We have other RNGs available.
> 
> Thank you.
> 
>> On Fri, Nov 9, 2018 at 3:23 PM Sven Van Caekenberghe  wrote:
>> Hi,
>> 
>> By accident I came across a pseudo random number generator that I never 
>> heard off before. It is supposed to be pretty good and had a very simple 
>> implementation. So I ported it to Pharo.
>> 
>> 
>> 
>> I am RandomWELL512, a random number generator.
>> 
>> I use the PRNG (Pseudo Randon Number Generator) WELL (Well equidistributed 
>> long-period linear) with a 512 bit state.
>> 
>>   https://en.wikipedia.org/wiki/Well_equidistributed_long-period_linear
>>   http://www.iro.umontreal.ca/~lecuyer/myftp/papers/wellrng.pdf
>> 
>> Implementation algorithm (See #nextUInt32)
>> 
>>   http://www.lomont.org/Math/Papers/2008/Lomont_PRNG_2008.pdf (Chris Lomont, 
>> www.lomont.org)
>> 
>> Usage
>> 
>>   RandomWELL512 new in: [ :r | (1 to: 10) collect: [ :i | r nextUInt32 ] ]. 
>> 
>>   RandomWELL512 new useUnixRandomGeneratorSeed; in: [ :r | (1 to: 10) 
>> collect: [ :i | r next ] ]. 
>> 
>>   RandomWELL512 new in: [ :r | (1 to: 10) collect: [ :i | r nextInt: 1000 ] 
>> ].
>> 
>>   RandomWELL512 new in: [ :random | | count all |
>> random useUnixRandomGeneratorSeed.
>> count := 1024 * 1024.
>> all := Array new: count streamContents: [ :out |
>>   count timesRepeat: [ out nextPut: random next ] ].
>> { all min. all max. all average. all stdev } ].
>> 
>>   [ RandomWELL512 new in: [ :random | 1 to: 1e6 do: [ :i | random next ] ] ] 
>> timeToRun.
>> 
>> Note that you should create one instance, seed it properly, and keep using 
>> it.
>> 
>> 
>> 
>> It is acceptably fast, generating 1M [0,1) Floats in about 0.1s. I compared 
>> the output with a fixed initial state to the C code that I started from and 
>> I got the same numbers. Maybe some people find this interesting.
>> 
>> I attached a file out.
>> 
>> Sven
>> 
>> 
>> 
> 
> 
> -- 
> 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] Cannot use Zinc in Pharo7 anymore

[Norbert Hartl]

> Am 06.11.2018 um 19:54 schrieb Stephane Ducasse :
> 
> Calypso is integral part of Pharo as Iceberg.
> We started to discuss the problem in the team. Right now this project
> spread kills us.
> 
It is not an easy decision. Either you bind everything closely to you and ease 
your workflow but have to do everything on your own. Or you welcome external 
projects not done by you and you enter modern dependency hell. Choose wisely or 
just try to solve the real problem. You neither have the time to develop 
everything by yourself nor have the patience to spend time on dependencies.

Norbert
> 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 the work to
>> make those parts work again. With forked repos, that can be a pharo
>> maintainer, the project maintainer or the application maintainer. All three
>> need to be able to make those changes. And they need to be decoupled from
>> having to make them immediately. And being able to have the discussion
>> about the exact implementation independently from implementing a stop-gap
>> solution now is also valuable.
>> 
>> So if Calypso is supposed to be extendable and only the core part is part
>> of Pharo, having it as an external project makes sense. With a fork for
>> Pharo to move at its own speed. If Iceberg is Pharo-only, just having
>> different branches for different Pharo versions, it sounds to me like it
>> might be better of in the Pharo project. Tonel is supposed to be
>> cross-platform so should be separate.
>> 
>> Is this helpful?
>> 
>> Stephan
>> 
>> 
>> 
> 

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

[Norbert Hartl]

> Am 02.11.2018 um 12:23 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> 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 the feedback loop is too long it means
>>> that
>>> we will prefer to work on our own projects (because we have also our
>>> own projects and there velocity is high and attractive).
>>> 
>>> I think that with github support this is simple to get the changes.
>>> Finally I heard that large companies developing large projects using
>>> github are managing one single repo: no subprojects, with their own PR
>>> and sync. And us little guys with our super clever brains we will
>>> succeed adding more constraints on the table.
>>> How bold are we. I'm impressed by such level of arrogance. This is why
>>> I do not like that Pharo gets managed in various repo
>>> because it kills us.
>>> 
>> Actually I was inquiring what everyone is doing to circumvent those problems 
>> (!!!). I have the same situation in my company. I’m the one that is 
>> reluctant to go to monorepo because I don’t like my code jailed in a 
>> project. But the effort we have to take in order to organize a stable and 
>> development version with a lot of external projects is killing us. So can we 
>> please talk about it? Pleaaassseee???
> 
> It is what it is today: there a some (a few) 'external' projects that are 
> part of the pharo image. For those, (most) allow changes in the pharo image, 
> while the maintainer of the external project merges them back upstream. That 
> is indeed the fastest cycle for pharo itself, but more work for the 
> maintainers.
> 
It seems I’m not very clear when writing mails. I understand why this happens 
and I understand it needs to be that way because of less annoyance and improved 
speed. I don’t understand how it is done explicitly. As we have a process that 
builds the image where are those changes applied? Is there a copy of the 
original package that gets tweaked?

> I believe the promise of Iceberg is that it would (maybe already is) just as 
> easy to do pull requests against against any repo. The future solution then 
> could be that each external project from the main image to their own repos.
> 
Yes, I’m getting used to git although I don’t like it. One reason I took 
several days time to help migrate projects from smalltalkhub to github is 
exactly this. In order to make myself independent I fork the projects I 
consider unstable and use the fork in our product. This way I have control when 
there is something updated. This could also be a good way for pharo. If there 
is a github project where every external project is forked to and used in 
pharo. This way you can control upstream and you can add tweaks that are needed 
for a release. I’m intrigued which approaches people do for what reasons.

> I want to add another aspect to this discussion: respect for the original 
> authors and current maint

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

[Norbert Hartl]

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 the feedback loop is too long it means
> that
> we will prefer to work on our own projects (because we have also our
> own projects and there velocity is high and attractive).
> 
> I think that with github support this is simple to get the changes.
> Finally I heard that large companies developing large projects using
> github are managing one single repo: no subprojects, with their own PR
> and sync. And us little guys with our super clever brains we will
> succeed adding more constraints on the table.
> How bold are we. I'm impressed by such level of arrogance. This is why
> I do not like that Pharo gets managed in various repo
> because it kills us.
> 
Actually I was inquiring what everyone is doing to circumvent those problems 
(!!!). I have the same situation in my company. I’m the one that is reluctant 
to go to monorepo because I don’t like my code jailed in a project. But the 
effort we have to take in order to organize a stable and development version 
with a lot of external projects is killing us. So can we please talk about it? 
Pleaaassseee???

Norbert

> Stef
> On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl  wrote:
>> 
>> 
>> 
>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe :
>>> 
>>> 
>>> 
>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe  wrote:
>>>> 
>>>> Norbert,
>>>> 
>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe  wrote:
>>>>> 
>>>>> I was planning on getting all changes to Zn/Zdc from pharo 7 back 
>>>>> upstream (and to GitHub), but I did not yet get around to it.
>>>> 
>>>> The current diff between Zn #bleedingEdge and Pharo 7 seems relatively 
>>>> minor, I will try to merge later tonight, at least the part in 
>>>> Zinc-Character-Encoding-Core that is causing you trouble.
>>> 
>>> Norbert,
>>> 
>>> I did a bunch of commits (both in the classic Zn MC repos as well as in 
>>> GitHub) that should help you, it works for me in any case. Zn #bleedingEdge 
>>> / HEAD is now in sync with Pharo 7 - it actually contains more.
>>> 
>>> Could you please test ?
>>> 
>> The first test I did was successful. There were popups for loading different 
>> zinc Versions but that is expected. I will test more today. Thanks for now. 
>> Can you please add tags in github for the version in smalltalkhub? Otherwise 
>> it is hard to switch.
>> 
>> Norbert
>> 
>> 
>> 
>> 
>> 
> 

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

[Norbert Hartl]

> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe  wrote:
>> 
>> Norbert,
>> 
>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe  wrote:
>>> 
>>> I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream 
>>> (and to GitHub), but I did not yet get around to it.
>> 
>> The current diff between Zn #bleedingEdge and Pharo 7 seems relatively 
>> minor, I will try to merge later tonight, at least the part in 
>> Zinc-Character-Encoding-Core that is causing you trouble.
> 
> Norbert,
> 
> I did a bunch of commits (both in the classic Zn MC repos as well as in 
> GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / 
> HEAD is now in sync with Pharo 7 - it actually contains more.
> 
> Could you please test ?
> 
The first test I did was successful. There were popups for loading different 
zinc Versions but that is expected. I will test more today. Thanks for now. Can 
you please add tags in github for the version in smalltalkhub? Otherwise it is 
hard to switch.

Norbert

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

[Norbert Hartl]

Hi,


> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe  wrote:
>> 
>> Norbert,
>> 
>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe  wrote:
>>> 
>>> I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream 
>>> (and to GitHub), but I did not yet get around to it.
>> 
>> The current diff between Zn #bleedingEdge and Pharo 7 seems relatively 
>> minor, I will try to merge later tonight, at least the part in 
>> Zinc-Character-Encoding-Core that is causing you trouble.
> 
> Norbert,
> 
> I did a bunch of commits (both in the classic Zn MC repos as well as in 
> GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / 
> HEAD is now in sync with Pharo 7 - it actually contains more.
> 
> Could you please test ?
> 
I think I have to. Usually it is not possible to load something from 
bleedingEdge and Zinc is used all over the place. But as it is you I change it 
;)

Norbert

[Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Norbert Hartl]

I asked this before because I don’t get it. External packages like Zinc seem to 
be modified when integrated into pharo. Looking at the changes between to 
newest Zinc from Sven’s repository and the one in pharo there are a few 
differences. As an example there is

ZnCharacterReadWriteStream>>#tab
   writeStream tab

Where is this method added? Are the changes pushed back to Sven? 

In my project I use Zinc-REST. So I need to add the repository for Zinc and 
load the REST group. When this is loaded it pulls in the other Zinc packages 
which removes the methods like the one above and my image gets stuck because 
Epicea relies on that method and I get a debugger.
So at the moment I can only create a new image when I disable Epicea.

Why is it done that way? Best would be to use the version from Sven and make 
changes there. If that is not possible it would be good to use an extra package 
that does extension methods to Zinc. But this way is asking for trouble IMHO.

Norbert

Re: [Pharo-dev] GitHub Topics

[Norbert Hartl]

> Am 13.10.2018 um 11:09 schrieb Cyril Ferlicot :
> 
> 
> 
>> On sam. 13 oct. 2018 at 10:42, Norbert Hartl  wrote:
>> I don‘t want to kick off another war but shouldn‘t we add pharo as a 
>> language to github. Now it is a topic but the configurations for linguist 
>> are still tying it to smalltalk. 
>> 
>> Norbert
>> 
>> 
> 
> Hi,
> 
> Linguist find the language based on theee things:
> - what is written on the .gitattribute file
> - the extension of the file
> - the source code (it compares it with examples)
> 
> Since multiple Smalltalk shares FileTree format and Tonel format, the 
> extensions and source code will be the same for Pharo and other Smalltalk.
> 
> Introducing a "Pharo" language would force everyone to add a .gitattribute 
> file to their project, and I'm sure not that many people will do it. 

That is not a problem because the ones that want to distinguish do and the rest 
does not. But after sending the message I started to think it would only make 
sense when we switch the file ending to something else then .st Maybe to big a 
change and not important enough.

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

Re: [Pharo-dev] GitHub Topics

[Norbert Hartl]

I don‘t want to kick off another war but shouldn‘t we add pharo as a language 
to github. Now it is a topic but the configurations for linguist are still 
tying it to smalltalk. 

Norbert

> Am 11.10.2018 um 16:28 schrieb Sean P. DeNigris :
> 
> Stephane Ducasse-3 wrote
>> super c00l
> 
> +1. Tagged all mine. Now one can search in "Pharo" topic for subcategories
> e.g. "authentication" shows 3 projects. Of course, the ideal is always to
> have everything in image, but this is really nice to have: 1) almost for
> free, 2) in a place like GH which is highly visible to the outside world and
> 3) without needing an image handy (e.g. one could look for a lib on a mobile
> device)
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] GitHub Topics

[Norbert Hartl]

Mine are tagged, too. And most of them have the gitattributed so is surely 
discovered as smalltalk

> Am 11.10.2018 um 03:48 schrieb Pierce Ng :
> 
>> On Wed, Oct 10, 2018 at 08:42:13AM -0300, Esteban Maringolo wrote:
>> PR approved! We're listed at https://github.com/topics/pharo
> 
> Great! I've tagged all my projects.
> 
> Pierce
> 
> 

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

[Norbert Hartl]

> Am 10.10.2018 um 15:58 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 10 Oct 2018, at 11:15, Norbert Hartl  wrote:
>> 
>> Very cool. Thank you very much,
>> 
>> Can you make releases for your repos? In my repos I did a release of a 
>> version saying it is the same as the last on smalltalkhub. So people can 
>> pinpoint to a specific release. I think this is a good way of doing it.
> 
> OK, I am still learning ;-)
> 
> What is the technical/practical differences between a tag and a release then ?

None :) On Github you press the button „Create a new release“ on git 
commandline you create a tag. Same same 

Norbert
> 
>> Norbert
>> 
>> 
>>> Am 05.10.2018 um 14:05 schrieb Sven Van Caekenberghe :
>>> 
>>> Hi,
>>> 
>>> I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. 
>>> So far I did the following:
>>> 
>>> https://github.com/svenvc/NeoJSON
>>> https://github.com/svenvc/NeoCSV
>>> https://github.com/svenvc/ztimestamp
>>> https://github.com/svenvc/P3
>>> https://github.com/svenvc/stamp
>>> https://github.com/svenvc/SimpleRedisClient
>>> https://github.com/svenvc/NeoConsole
>>> 
>>> More will follow, in particular Zinc/Zodiac and STON, both of which are 
>>> more complex.
>>> 
>>> The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. 
>>> By loading the latest Metacello and Tonel, the code is also loadable in 
>>> Pharo 6 or 5.
>>> 
>>> After a while I will switch the Catalog entries and declare these repo the 
>>> main ones.
>>> 
>>> Sven
>>> 
>>> --
>>> Sven Van Caekenberghe
>>> Proudly supporting Pharo
>>> http://pharo.org
>>> http://association.pharo.org
>>> http://consortium.pharo.org
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

[Norbert Hartl]

Very cool. Thank you very much,

Can you make releases for your repos? In my repos I did a release of a version 
saying it is the same as the last on smalltalkhub. So people can pinpoint to a 
specific release. I think this is a good way of doing it.

Norbert


> Am 05.10.2018 um 14:05 schrieb Sven Van Caekenberghe :
> 
> Hi,
> 
> I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. 
> So far I did the following:
> 
> https://github.com/svenvc/NeoJSON
> https://github.com/svenvc/NeoCSV
> https://github.com/svenvc/ztimestamp
> https://github.com/svenvc/P3
> https://github.com/svenvc/stamp
> https://github.com/svenvc/SimpleRedisClient
> https://github.com/svenvc/NeoConsole
> 
> More will follow, in particular Zinc/Zodiac and STON, both of which are more 
> complex.
> 
> The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. 
> By loading the latest Metacello and Tonel, the code is also loadable in Pharo 
> 6 or 5.
> 
> After a while I will switch the Catalog entries and declare these repo the 
> main ones.
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 
> 

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

[Norbert Hartl]

Great! And yet another reminder that all projects should consider moving to git.

Norbert

> Am 05.10.2018 um 14:05 schrieb Sven Van Caekenberghe :
> 
> Hi,
> 
> I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. 
> So far I did the following:
> 
> https://github.com/svenvc/NeoJSON
> https://github.com/svenvc/NeoCSV
> https://github.com/svenvc/ztimestamp
> https://github.com/svenvc/P3
> https://github.com/svenvc/stamp
> https://github.com/svenvc/SimpleRedisClient
> https://github.com/svenvc/NeoConsole
> 
> More will follow, in particular Zinc/Zodiac and STON, both of which are more 
> complex.
> 
> The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. 
> By loading the latest Metacello and Tonel, the code is also loadable in Pharo 
> 6 or 5.
> 
> After a while I will switch the Catalog entries and declare these repo the 
> main ones.
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 
> 

Re: [Pharo-dev] Loading GitHub/Tonel/BaselineOf code in Pharo 6.0

[Norbert Hartl]

> Am 03.10.2018 um 14:02 schrieb Sven Van Caekenberghe :
> 
> So I am trying to load GitHub/Tonel/BaselineOf code in Pharo 6.0.
> 
> I got a fresh 6.0 and I installed Tonel into it using
> 
> Metacello new 
>  repository: 'github://pharo-vcs/tonel';
>  baseline: 'Tonel';
>  load.
> 
> Which went OK
> 
> Fetched -> BaselineOfTonel-cypress.1 --- github://pharo-vcs/tonel:master 
> [0317649:master] --- github://pharo-vcs/tonel:master
> Loaded -> BaselineOfTonel-cypress.1 --- github://pharo-vcs/tonel:master 
> [0317649:master] --- github://pharo-vcs/tonel:master
> Loading baseline of BaselineOfTonel...
> Fetched -> MonticelloTonel-Core-cypress.1 --- github://pharo-vcs/tonel:master 
> [0317649:master] --- github://pharo-vcs/tonel:master
> Fetched -> MonticelloTonel-FileSystem-cypress.1 --- 
> github://pharo-vcs/tonel:master [0317649:master] --- 
> github://pharo-vcs/tonel:master
> Fetched -> MonticelloTonel-Tests-cypress.1 --- 
> github://pharo-vcs/tonel:master [0317649:master] --- 
> github://pharo-vcs/tonel:master
> Loaded -> MonticelloTonel-Core-cypress.1 --- github://pharo-vcs/tonel:master 
> [0317649:master] --- cache
> Loaded -> MonticelloTonel-FileSystem-cypress.1 --- 
> github://pharo-vcs/tonel:master [0317649:master] --- cache
> Loaded -> MonticelloTonel-Tests-cypress.1 --- github://pharo-vcs/tonel:master 
> [0317649:master] --- cache
> ...finished baseline
> 
> Then I try to load some code from me that has been converted to 
> GitHub/Tonel/BaselineOf and that works fine in 6.1/7.0 and contains all meta 
> info
> 
> Metacello new 
>  repository: 'github://svenvc/ztimestamp';
>  baseline: 'ZTimestamp';
>  load.
> 
> This fails
> 
> ...RETRY->BaselineOfZTimestamp
> ...RETRY->BaselineOfZTimestamp
> ...FAILED->BaselineOfZTimestamp
> 
> Could not resolve: BaselineOfZTimestamp [BaselineOfZTimestamp] in 
> /Users/sven/Tmp/pharo6/pharo-local/package-cache 
> github://svenvc/ztimestamp:master
> 
> What am I doing wrong here ?
> 
That is the behaviour I was talking about. Tonel in my case had read problem at 
the end of the stream. But I couldn‘t figure out what it is

Norbert
> Thx,
> 
> Sven
> 
> 

Re: [Pharo-dev] [Pharo-users] [ANN] Success story Mobility Map

[Norbert Hartl]

> Am 30.09.2018 um 13:01 schrieb Pierce Ng :
> 
> On Wed, Sep 26, 2018 at 07:49:10PM +0200, Norbert Hartl wrote:
>>>> And a lot more. This is a coarse grained overview over the
>>>> architecture. I’m happy to answer further questions about this.
>>>> [very nice writeup]
> 
> Hi Norbert,
> 
> Very nice write-up, thanks. 
> 
thanks

> What persistence mechanism are you using - Gemstone/S, Glorp, Voyage, …?

We use voyage with a mongo replica set. 

Norbert

Re: [Pharo-dev] [Pharo-users] [ANN] Success story Mobility Map

[Norbert Hartl]

> Am 26.09.2018 um 19:22 schrieb Nicolas Cellier 
> :
> 
> Very nice proof that we can leverage efficient and up to date technologies !

That was part of the plan ;)

> Thank you so much for sharing, that's the right way to make Pharo (and 
> Smalltalk) alive and kicking. How did the Pharo IDE help in such context? 
> (did you use debugging facility extensively?).
> What tool is missing?

At first pharo is always a bliss to work with. In such a project I try to make 
the whole application managable on different levels. The most important one is 
to have the whole application in one image. We have tests for the broker and 
for each micro service. But we also have tests that operate on the whole stack. 
Here the Q is being shortcut and handling is more synchronous than in the Q 
case. With this it is easier to get a stack in the debugger of the whole 
roundtrip. 

Using docker we can have the whole application started on a local laptop. This 
way all components are much closer to investigate. We can switch the frontend 
server with a local development entity. I started to do that for the pharo 
images but did not finish yet. The idea is to start the same stack as in the 
swarm but replace one image with an actual development image where you can use 
the debugger.

On the swarm itself we configure each microservice to upload a fuel context 
dump to a central server on exception. From my development image I have a 
simple client to look for exceptions for a project and version number. Clicking 
on one it downloads the dump and opens a debugger locally. I can fix the bug 
and commit with iceberg. This goes well with our continuous deployment. When a 
commit is done, jenkins builds the whole product and deploys that automatically 
on the alpha swarm. This way from seeing an error the only thing to do is 
clicking on it solve the problem in the debugger and commit. Well, in most of 
the cases ;)

What I’m working on and gave a quick preview on ESUg is to have a client for 
docker swarm. It is another way to close the cycle to use pharo to manage 
things in a swarm that is build from pharo images. I did a first prototype how 
to connect on a particular image in the swarm and start TelePharo on it so you 
can set breakpoints for certain things and have a debugger in your image from 
the live swarm. 

The last things we did is to add proper monitoring of metrics withing the 
service so you can spot problems that belong to any kind of resource shortage. 
In this case it would be especially useful to connect to such an image to do 
live investigations. Yes and object centric debugging/logging will help here 
Steven/guys ;)

Or two say it in less words :) The two problems we had to solve is to remove 
complexity where possible and to have all the mentioned approaches to enable 
our team to tackle an occurring problem from different angles. If no one is 
blocked in work the project does not stagnate. It is not a guarantee to succeed 
but a requirement

Hope this is the information you were asking for.

Norbert

> 
> Le mar. 25 sept. 2018 à 17:45, Sven Van Caekenberghe  <mailto:s...@stfx.eu>> a écrit :
> 
> 
> > On 25 Sep 2018, at 14:39, Norbert Hartl  > <mailto:norb...@hartl.name>> wrote:
> > 
> > 
> > 
> >> Am 25.09.2018 um 12:52 schrieb Sven Van Caekenberghe  >> <mailto:s...@stfx.eu>>:
> >> 
> >> Wow. Very nice, well done.
> >> 
> >> Any chance on some more technical details, as in what 'connected by a 
> >> message queue for the communication' exactly means ? How did you approach 
> >> micro services exactly ?
> >> 
> > Sure :)
> 
> Thanks, this is very interesting !
> 
> > The installation spawns multiple physical machines. All the machines are 
> > joined to a docker swarm. The installation is reified as either task or 
> > service from the view on the docker swarm. Meaning you instantiate an 
> > arbitrary amount of services and docker swarm distributes them among the 
> > physical machines. Usually you don’t take control which is running where 
> > but you can. At this point you have spread dozens of pharo images among 
> > multiple machines and each of them has an IP address. Furthermore in docker 
> > swarm you have a reification of a network meaning that every instance in a 
> > network can see all other instances on this network. Each service can be 
> > reached by its service name in that network. Docker swarm does all the 
> > iptables/firewall and DNS setup for you.
> 
> Are you happy with docker swarm's availability/fail-over behaviour ? In other 
> words: does it work when one image/instance goes bad, does it detect and 
> restore the missing functionality ?
> 
> > In order to have communication between those runtimes we use rab

Re: [Pharo-dev] [Pharo-users] [ANN] Migrated Artefact to GitHub

[Norbert Hartl]

Super! Thanks

Norbert

> Am 27.09.2018 um 11:26 schrieb Guillermo Polito :
> 
> Hi all,
> 
> I've moved the Artefact library to GitHub 
> (https://github.com/pharo-contributions/Artefact).
> 
> I've also made some changes to it in the way and made a 1.7.0 version with:
>  - support for Pharo7 streams
>  - a baseline
> 
> So, people using Artifact, you can contribute through pull requests ^^,
> Guille
> 
> -- 
>
> 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-users] [ANN] Success story Mobility Map

[Norbert Hartl]

> Am 25.09.2018 um 17:44 schrieb Sven Van Caekenberghe :
> 
> 
> 
>> On 25 Sep 2018, at 14:39, Norbert Hartl  wrote:
>> 
>> 
>> 
>>> Am 25.09.2018 um 12:52 schrieb Sven Van Caekenberghe :
>>> 
>>> Wow. Very nice, well done.
>>> 
>>> Any chance on some more technical details, as in what 'connected by a 
>>> message queue for the communication' exactly means ? How did you approach 
>>> micro services exactly ?
>>> 
>> Sure :)
> 
> Thanks, this is very interesting !
> 
>> The installation spawns multiple physical machines. All the machines are 
>> joined to a docker swarm. The installation is reified as either task or 
>> service from the view on the docker swarm. Meaning you instantiate an 
>> arbitrary amount of services and docker swarm distributes them among the 
>> physical machines. Usually you don’t take control which is running where but 
>> you can. At this point you have spread dozens of pharo images among multiple 
>> machines and each of them has an IP address. Furthermore in docker swarm you 
>> have a reification of a network meaning that every instance in a network can 
>> see all other instances on this network. Each service can be reached by its 
>> service name in that network. Docker swarm does all the iptables/firewall 
>> and DNS setup for you.
> 
> Are you happy with docker swarm's availability/fail-over behaviour ? In other 
> words: does it work when one image/instance goes bad, does it detect and 
> restore the missing functionality ?
> 
Yes, I‘m very satisified. Instances are automatically restarted if they crash. 
And not necessarily on the same machine exactly how I expect it. Docker has 
something called Healthcheck. You can have a command executed every 20 seconds. 
I hooked this to a curl command and to your SUnit Rest handler. The rest is 
writing unit tests for server health. If tests fail in sequence the instances 
are taken out of operation and are replaced with a new instance. The same is 
done for updating. Instances are started in a fashion that one instance of the 
new image is started, if it survives a couple of health checks it is taken 
operational and an old one is taken out. Then the next new is started... For 
simple software updates you have zero-downtime deployment. 

>> In order to have communication between those runtimes we use rabbitmq 
>> because you were so nice writing a driver for it ;) The rabbitmq does have a 
>> support for cluster setup, meaning each of the physical machines has a 
>> rabbitmq installation and they know each other. So it does not matter to 
>> which instance you send messages to and on which you register for receiving 
>> messages. So every pharo image connects to the service rabbitmq and opens a 
>> queue for interaction.
> 
> Same question: does RabbitMQ's clustering work well under stress/problems ? 
> Syncing all queues between all machines sounds quite heavy (I never tried it, 
> but maybe it just works).

I did not yet have time to real stress test the queue. And you are right 
copying between nodes might be a lot but still I have the feeling it is better 
to have then a single instance but no  real reason. We also use huge payloads 
which might have to change if we encounter problems.
> 
>> Each service like the car sharing opens a queue e.g. /queue/carSharing and 
>> listens on it. The broker images are stateful so they open queues like 
>> /queue/mobility-map-afdeg32 where afdeg32 is the container id of the 
>> instance (hostname in docker). In each request the queue name to reply is 
>> sent as a header. So we can make sure that the right image gets the message 
>> back. This way we can have sticky sessions keeping volatile data in memory 
>> for the lifecycle of a session. There is one worker image which opens a 
>> queue /queue/mobility-map where session independent requests can be 
>> processed. 
> 
> I think I understand ;-)
> 
>> In order to ease development we are sharing code between the broker and the 
>> micro service. Each micro service has a -Common package where the classes 
>> are in that build the interface. The classes in here are a kind of data 
>> entity facades. They use NeoJSON to map to and from a stream. The class name 
>> is send with the message as a header so the remote side knows what to 
>> materialize. The handling is unified for the four cases 
>> 
>> - Request as inquiry to another micro service
>> - Response returns values to a Request
>> - Error is transferred like a Response but is then signalled on the 
>> receiving side
>> - Notification connects the announcers on the broker and the micro ser

[Pharo-dev] IoT hackathon @zweidenker

[Norbert Hartl]

Hi,

we (ZWEIDENKER) and RModD organized an IoT Hackathon in cologne at 19th of 
october 2018. The plan will be:

- Allex Oliviera will present the tutorial he made on PharoThings [1]. The 
audience will try it in a hands-on-session and give feedback to improve it. 
Zweidenker is sponsoring the hardware so nobody has to bring anything to the 
session
- We are collecting ideas at the moment what we want to do with the learnings 
from Allex, meaning what hardware to build 
- If you have ideas about what to build with real life things that should be 
connected from pharo, please tell us. We will compile a list of ideas and for 
the first two or three we will buy the necessary hardware so we can build it at 
that day

The Hackathon will take place at

ZWEIDENKER GmbH
Luxemburger Str. 72
50674 Köln
germany

As we have a limited amount of seats you need to register if you are 
interested. Go to http://zweidenker.de/en/iot-hackathon-2018 
 to register your seat on the 
session. If there are more participants than seats we will have to do selection 
by dice rolling. Registration period ends on 5th of october so you will know in 
advance if you can come.

See you there,

Norbert on behalf of ZWEIDENKER

[1] https://github.com/pharo-iot/PharoThings 

Re: [Pharo-dev] [ANN] Success story Mobility Map

[Norbert Hartl]

> Am 25.09.2018 um 12:52 schrieb Sven Van Caekenberghe :
> 
> Wow. Very nice, well done.
> 
> Any chance on some more technical details, as in what 'connected by a message 
> queue for the communication' exactly means ? How did you approach micro 
> services exactly ?
> 
Sure :)

The installation spawns multiple physical machines. All the machines are joined 
to a docker swarm. The installation is reified as either task or service from 
the view on the docker swarm. Meaning you instantiate an arbitrary amount of 
services and docker swarm distributes them among the physical machines. Usually 
you don’t take control which is running where but you can. At this point you 
have spread dozens of pharo images among multiple machines and each of them has 
an IP address. Furthermore in docker swarm you have a reification of a network 
meaning that every instance in a network can see all other instances on this 
network. Each service can be reached by its service name in that network. 
Docker swarm does all the iptables/firewall and DNS setup for you.

In order to have communication between those runtimes we use rabbitmq because 
you were so nice writing a driver for it ;) The rabbitmq does have a support 
for cluster setup, meaning each of the physical machines has a rabbitmq 
installation and they know each other. So it does not matter to which instance 
you send messages to and on which you register for receiving messages. So every 
pharo image connects to the service rabbitmq and opens a queue for interaction.

Each service like the car sharing opens a queue e.g. /queue/carSharing and 
listens on it. The broker images are stateful so they open queues like 
/queue/mobility-map-afdeg32 where afdeg32 is the container id of the instance 
(hostname in docker). In each request the queue name to reply is sent as a 
header. So we can make sure that the right image gets the message back. This 
way we can have sticky sessions keeping volatile data in memory for the 
lifecycle of a session. There is one worker image which opens a queue 
/queue/mobility-map where session independent requests can be processed. 

In order to ease development we are sharing code between the broker and the 
micro service. Each micro service has a -Common package where the classes are 
in that build the interface. The classes in here are a kind of data entity 
facades. They use NeoJSON to map to and from a stream. The class name is send 
with the message as a header so the remote side knows what to materialize. The 
handling is unified for the four cases 

- Request as inquiry to another micro service
- Response returns values to a Request
- Error is transferred like a Response but is then signalled on the receiving 
side
- Notification connects the announcers on the broker and the micro service side.

Asynchronous calls we solved using Promises and Futures. Each async call to the 
Q becomes a promise (that blocks on #value) and is combined to a future value 
containing all promises with support to generate a delta of all resolved 
promises. This we need because you issue a search that takes longer and you 
want to display results as soon as they are resolved not after all haven been 
resolved.

And a lot more. This is a coarse grained overview over the architecture. I’m 
happy to answer further questions about this.

Norbert

>> On 25 Sep 2018, at 12:20, Norbert Hartl  wrote:
>> 
>> As presented on ESUG here is the brief description of one of our current 
>> projects. 
>> 
>> Mobility Map
>> ——
>> 
>> Mobility Map is a broker for mobility services. It offers multi-modal 
>> routing search enabling users to find the best travel options between 
>> locations. Travel options include car sharing, bikes, trains, busses etc. 
>> Rented cars can be offered for ride sharing on booking time letting other 
>> people find it to participate in the ride. Single travel options are 
>> combined in travel plans that can be booked and managed in a very easy way. 
>> 
>> For this project main requirements were scalability to serve a large user 
>> base and flexibility to add more additional providers to the broker. The 
>> application has been realized using web technologies for the frontend and 
>> pharo for the backend. Using a microservice architecture combined with a 
>> broker it is easy to extend the platform with additional brokers. Deployment 
>> is done using docker swarm for distributing dozens of pharo images among 
>> multiple server machines connected by a message queue for the communication. 
>> Pharo supported that scenario very well enabling us the meet the 
>> requirements with less effort. 
>> 
>> Pharo turned out to be a perfect fit to develop the application in a agile 
>> way. Small development cycles with continuous integration and continuous 
>> delivery enables fast turnarounds for the customers to validate progress.
>> 
>> This is a screenshot of the search page for multi-modal results:
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] Extension methods in p7

[Norbert Hartl]

Denis,

I have the same in voyage, too. Marcus gave a possible reference for this

https://github.com/pharo-project/pharo/pull/1685/files 
<https://github.com/pharo-project/pharo/pull/1685/files>

Norbert

> Am 21.08.2018 um 10:05 schrieb Denis Kudriashov :
> 
> Hi Norbert.
> 
> In Calypso there are no protocols for extensions. You should simply call 
> command Move methods to package either from menu or drag and drop to package 
> (where you see it).
> 
> I don't know what the reason for commit and removal. I will check.
> 
> вт, 21 авг. 2018 г., 8:32 Norbert Hartl  <mailto:norb...@hartl.name>>:
> I’m about preparing magritte to be loadable in pharo 7. I encountered a bit 
> strange behaviour where I had to take cumbersome measures. Magritte has 
> method extensions that are called e.g.
> 
> *Magritte-model-builder
> 
> These methods get loaded but when I commit something all of these methods are 
> to be removed. The only thing I could do was to rename the extension methods. 
> Is this intended? 
> Doing the renaming I encountered of few things. Magritte had the extension 
> method above in the Magritte-Model package. When I rename the category 
> *Magritte-model-builder to *Magritte-Model the method gets removed. Not a 
> very usual case but still strange.
> In order to create a method extension one needs first to create a new 
> protocol before converting to extension method. If the new protocol is empty 
> and you convert it to an extension method it gets removed. So I had to first 
> create a protocol, move a method in and then convert. This combined with the 
> behaviour that if you select two methods the method pane jumps to the 
> beginning of the list is a lot of work just to do this job. Still it is not a 
> very usual case but some might be interested.
> 
> Norbert
> 
>