[Pharo-users] [ANN] SmalltalkHub Deprecation Notice

[Guillermo Polito]

SmalltalkHub Deprecation Notice
SmalltalkHub is now getting old and it is time to deprecate it. We plan to 
replace it by a static file server during 2020. The public data will still be 
readable and consumable from monticello clients, but modifications will not be 
allowed in the near future. SmalltalkHub users should move their projects to 
git repositories or other monticello repository services.
What is changing?
If you currently host a project in SmalltalkHub, you should migrate your 
projects to another platform as soon as possible. If you depend on a project 
hosted on SmalltalkHub, you should contact the owner of that project to 
schedule a migration.
If you have documentation or tutorials using SmalltalkHub, we recommend to 
update those after a migration.
An archive of all public projects in SmalltalkHub will be made available in 
read-only mode. This archive will be readable through monticello clients for 
compatibility reasons.
Private projects, due to privacy reasons, will not be published in the public 
archive and will be removed to protect their owners.
Why are RMoD and Inria making this change?
SmalltalkHub has finished its cycle. The arrival of git integration in the past 
years caused the move of most users in the Pharo community to git hosting 
services. They now use exclusively other platforms. Furthermore, RMoD and Inria 
lack the manpower to properly maintain the SmalltalkHub service and keep it up 
to date. Smalltalkhub has no added value compared to other code source hosting 
platforms.
How much time do I have to adapt to this change?

The SmalltalkHub deprecation will follow the next timetable:
Monday 04 of may 2020: SmalltalkHub will be read-only. Creation of new users 
and projects will be forbidden. New commits will be rejected. All existing 
users, projects (public and private) and their commits will remain available 
and visible, but their settings will become read-only.
Monday 02 of november 2020: SmalltalkHub will be migrated to a static file 
server archive. Private projects and their commits will not be available 
anymore.

The RMoD team and Inria plan to keep the static file server alive for, at 
least, 5 years from the date of its creation.
What will happen if I do nothing?
Your public projects will become read-only and you will not be able to commit 
anymore.
Your private projects will become unavailable.
What alternatives do I have?

Those wanting to keep using monticello can migrate their projects to other 
monticello hostings such as http://squeaksource.com  
or http://ss3.gemstone.com 
Those wanting to migrate to git, Peter Uhnak’s git migration tool 
(https://github.com/peteruhnak/git-migration 
) automates monticello to git 
migration in tonel format.

Cheers,
Guille on behalf of the RMoD team

Re: [Pharo-users] Latest PharoJS Success Story

[Noury Bouraqadi]

Hi Shaping,

> On 3 Apr 2020, at 06:09, Shaping  wrote:
> 
> Hi Noury.
> 
> Brain Treats got stuck during launch on my LG.
> 
Which android version are you using ?

> Is there a plan to move PharoJS to Wasm/WASI?
> 
Dave and I talked about it a long time ago. This sounds like a good idea.
Actually, Dave has a very ambition idea = turn PharoJS into Pharo* where * can 
be different targets.
But, there's a lot to do before reaching this goal. So, don't expect it any 
time soon.

Noury
> 
> Shaping
> 
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
> N. Bouraqadi
> Sent: Tuesday, 28 January, 2020 12:18
> To: Any question about pharo is welcome 
> Subject: [Pharo-users] Latest PharoJS Success Story
> 
> The latest PharoJS-powered smartphone app is now live.
> Development has been made using Pharo.
> Then, javascript code is generated using PharoJS.
> Last, the app is built to target both iOS and Android thanks to Apache
> Cordova.
> 
> Learn more and Download at
> https://nootrix.com/projects/brain-treats-app/
> 
> Noury
> 
> 

Re: [Pharo-users] [ANN] SmalltalkHub Deprecation Notice

[Renaud de Villemeur via Pharo-users]

--- Begin Message ---
Hi Guille.

It's a good news to see the community is moving forward. 

What would be the impact on Pharo catalog ? The instruction still advise to 
upload information to smalltalkhub: 
http://catalog.pharo.org/catalog/note-for-developers?_s=bHk4XDBcH9mb0muM&_k=WPHmGPa_-V3tv21k
Will it be deprecated as well ? 

Thanks
Renaud




Apr. 3, 2020, 05:55 by guillermopol...@gmail.com:

> SmalltalkHub Deprecation Notice
> SmalltalkHub is now getting old and it is time to deprecate it. We plan to 
> replace it by a static file server during 2020. The public data will still be 
> readable and consumable from monticello clients, but modifications will not 
> be allowed in the near future. SmalltalkHub users should move their projects 
> to git repositories or other monticello repository services.
> What is changing?
> If you currently host a project in SmalltalkHub, you should migrate your 
> projects to another platform as soon as possible. If you depend on a project 
> hosted on SmalltalkHub, you should contact the owner of that project to 
> schedule a migration.
> If you have documentation or tutorials using SmalltalkHub, we recommend to 
> update those after a migration.
> An archive of all public projects in SmalltalkHub will be made available in 
> read-only mode. This archive will be readable through monticello clients for 
> compatibility reasons.
> Private projects, due to privacy reasons, will not be published in the public 
> archive and will be removed to protect their owners.
> Why are RMoD and Inria making this change?
> SmalltalkHub has finished its cycle. The arrival of git integration in the 
> past years caused the move of most users in the Pharo community to git 
> hosting services. They now use exclusively other platforms. Furthermore, RMoD 
> and Inria lack the manpower to properly maintain the SmalltalkHub service and 
> keep it up to date. Smalltalkhub has no added value compared to other code 
> source hosting platforms.
> How much time do I have to adapt to this change?
>
> The SmalltalkHub deprecation will follow the next timetable:
> Monday 04 of may 2020: SmalltalkHub will be read-only. Creation of new users 
> and projects will be forbidden. New commits will be rejected. All existing 
> users, projects (public and private) and their commits will remain available 
> and visible, but their settings will become read-only.
> Monday 02 of november 2020: SmalltalkHub will be migrated to a static file 
> server archive. Private projects and their commits will not be available 
> anymore.
>
> The RMoD team and Inria plan to keep the static file server alive for, at 
> least, 5 years from the date of its creation.
> What will happen if I do nothing?
> Your public projects will become read-only and you will not be able to commit 
> anymore.
> Your private projects will become unavailable.> What alternatives do I have?
>
> Those wanting to keep using monticello can migrate their projects to other 
> monticello hostings such as > http://squeaksource.com 
> >  or>  http://ss3.gemstone.com
>
> Those wanting to migrate to git, Peter Uhnak’s git migration tool (> 
> https://github.com/peteruhnak/git-migration> ) automates monticello to git 
> migration in tonel format.
>
> Cheers,
> Guille on behalf of the RMoD team
>

--- End Message ---

Re: [Pharo-users] How should XMLHTMLParser handle strange HTML?

[Michal Balda]

Hello Peter,

Those are called conditional comments. They come from MS Word which is 
used as the HTML rendering engine for MS Outlook. There is not much 
documentation available online specifically for MS Word but they were 
also implemented in older versions of MS Internet Explorer and used 
commonly by web designers to fix bugs and quirks in IE's rendering. See 
Wikipedia:



https://en.wikipedia.org/wiki/Conditional_comment

Or just search for 
"internet explorer conditional comments", you will find plenty of resources.


The ones in your example are the "downlevel-revealed" sort of 
conditional comments meaning that the content between the "if" and 
"endif" is visible to all browsers. The "if" and "endif" themselves are 
recognized by MS Word (and MS Internet Explorer) and evaluated as 
conditions while they are ignored by other web browsers.


The syntax is based on the original SGML syntax which is the precursor 
to HTML. In this form it is invalid in HTML but standard browsers can 
handle it and do the meaningful thing. There exists an alternative form 
(also described by the Wikipedia page) which is valid HTML and still 
works as a conditional comment:





Just converting it to "" causes it to lose its 
meaning: it won't be recognized any more but if you don't need to open 
it in MS Word again it doesn't matter.


To answer your question: What should an HTML parser do? I think it 
depends on the use case. What XMLHTMLParser does now is wrong. To be 
correct, it could signal an error since it's invalid HTML (like an HTML 
validator would), or it could ignore the syntax error in an unknown 
element and continue parsing (like a browser would). Standard HTML 
processors choose the second approach and try to fix what they can to 
produce what they think is most meaningful. In this case they are smart 
enough to realize that it's probably meant to be a comment. To me, 
something like a resumable exception would be acceptable: one could make 
two wrappers, a strict one and a loose one, and choose the one that 
better fits the situation.


(An XML parser, on the other hand, must always signal an exception and 
abort parsing in case of a syntax error, as per the specification.)



Michal



On 2.4.2020 19:16, PBKResearch wrote:


Hello

I have come across a strange problem in using XMLHTMLParser to parse 
some HTML files which use strange constructions. The input files have 
been generated by using MS Outlook to translate incoming messages, 
stored in .msg files, into HTML. The translated files display normally 
in Firefox, and the XMLHTMLParser appears to generate a normal parse, 
but examination of the parse output shows that the structure is 
distorted, and about half the input text has been put into one string 
node.


Hunting around, I am convinced that the trouble lies in the presence 
in the HTML source of pairs of comment-like tags, with this form:






since the distorted parse starts at the first occurrence of one of 
these tags.


I don’t know whether these are meant to be a structure in some 
programming language – there is no reference to supportLists anywhere 
in the source code. When it is displayed in Firefox, use of the 
‘Inspect Element’ option shows that the browser has treated them as 
comments, displaying them with the necessary dashes as e.g. . I edited the source code by inserting the dashes, 
and XMLHTMLParser parsed everything correctly.


I have a workaround, therefore; either edit in the dashes to make them 
into legitimate comments, or equivalently edit out these tags 
completely. The only question of general interest is whether 
XMLHTMLParser should be expected to handle these in some other way, 
rather than produce a distorted parse without comment. The Firefox 
approach, turning them into comments, seems sensible. It would also be 
interesting if anyone has any idea what is going on in the source code.


Thanks for any help

Peter Kenny

Re: [Pharo-users] [rmod] [ANN] SmalltalkHub Deprecation Notice

[Guillermo Polito]

Hi Renaud,


> El 3 abr 2020, a las 16:27, Renaud de Villemeur  
> escribió:
> 
> Hi Guille.
> 
> It's a good news to see the community is moving forward. 
> 
> What would be the impact on Pharo catalog ? The instruction still advise to 
> upload information to smalltalkhub: 
> http://catalog.pharo.org/catalog/note-for-developers?_s=bHk4XDBcH9mb0muM&_k=WPHmGPa_-V3tv21k
>  
> 
> Will it be deprecated as well ? 

My *personal* take on this is is that we can migrate easily the catalog, 
without deprecating it:
 - the catalog repositories will stay alive as read-only, so it will be no 
problem to access old catalog entries (unless they depend on private projects, 
but that would be odd)
 - a low-energy solution for this is to migrate these repositories to 
squeaksource3. This should be mostly straight-forward.
 - a high-energy solution is to rethink the catalog. I know there have been 
some community efforts from Christophe Demarey for example, Esteban has also 
interesting ideas on how to attack this.

Thoughts?

> 
> Thanks
> Renaud
> 
> 
> 
> 
> Apr. 3, 2020, 05:55 by guillermopol...@gmail.com:
> SmalltalkHub Deprecation Notice
> SmalltalkHub is now getting old and it is time to deprecate it. We plan to 
> replace it by a static file server during 2020. The public data will still be 
> readable and consumable from monticello clients, but modifications will not 
> be allowed in the near future. SmalltalkHub users should move their projects 
> to git repositories or other monticello repository services.
> What is changing?
> If you currently host a project in SmalltalkHub, you should migrate your 
> projects to another platform as soon as possible. If you depend on a project 
> hosted on SmalltalkHub, you should contact the owner of that project to 
> schedule a migration.
> If you have documentation or tutorials using SmalltalkHub, we recommend to 
> update those after a migration.
> An archive of all public projects in SmalltalkHub will be made available in 
> read-only mode. This archive will be readable through monticello clients for 
> compatibility reasons.
> Private projects, due to privacy reasons, will not be published in the public 
> archive and will be removed to protect their owners.
> Why are RMoD and Inria making this change?
> SmalltalkHub has finished its cycle. The arrival of git integration in the 
> past years caused the move of most users in the Pharo community to git 
> hosting services. They now use exclusively other platforms. Furthermore, RMoD 
> and Inria lack the manpower to properly maintain the SmalltalkHub service and 
> keep it up to date. Smalltalkhub has no added value compared to other code 
> source hosting platforms.
> How much time do I have to adapt to this change?
> 
> The SmalltalkHub deprecation will follow the next timetable:
> Monday 04 of may 2020: SmalltalkHub will be read-only. Creation of new users 
> and projects will be forbidden. New commits will be rejected. All existing 
> users, projects (public and private) and their commits will remain available 
> and visible, but their settings will become read-only.
> Monday 02 of november 2020: SmalltalkHub will be migrated to a static file 
> server archive. Private projects and their commits will not be available 
> anymore.
> 
> The RMoD team and Inria plan to keep the static file server alive for, at 
> least, 5 years from the date of its creation.
> What will happen if I do nothing?
> Your public projects will become read-only and you will not be able to commit 
> anymore.
> Your private projects will become unavailable.
> What alternatives do I have?
> 
> Those wanting to keep using monticello can migrate their projects to other 
> monticello hostings such as http://squeaksource.com 
>  or http://ss3.gemstone.com 
> 
> 
> Those wanting to migrate to git, Peter Uhnak’s git migration tool 
> (https://github.com/peteruhnak/git-migration 
> ) automates monticello to git 
> migration in tonel format.
> 
> Cheers,
> Guille on behalf of the RMoD team
> 

Re: [Pharo-users] Latest PharoJS Success Story; Wasm/WASI; very keen on Pony for the Pharo VM

[Shaping]

All:

> Brain Treats got stuck during launch on my LG.

> 

Which android version are you using ?

 

The phone is old and this is likely the problem.

 

Android version:  4.4.2

Kernel version:  3.4.0

 

> Is there a plan to move PharoJS to Wasm/WASI?

> 

Dave and I talked about it a long time ago. This sounds like a good idea.

Actually, Dave has a very ambition idea = turn PharoJS into Pharo* where *
can be different targets.

But, there's a lot to do before reaching this goal. So, don't expect it any
time soon.

 

Not to change the topic too much, but the following is related and I often
think of it.

 

Consider writing the pharo VM in Wasm or, better, with Pony (which can emit
Wasm, as needed).  Pony's reference-capability-based (ref-cap)
concurrency-model guarantees provably that no data-races or deadlocks can
happen if the code compiles; this solves a very large class of extremely
ugly concurrency problems that no one ever wants to face. 

 

Pony gives high-performance concurrency (5 to 15 ns actor-thread switching
time, depending on platform), and solves the most difficult class of
synchronization problems at compile time.  It runs as fast as C.  It runs
faster than C, as concurrency scales.  You can't scale a highly concurrent
app efficiently in C, and really shouldn't try if you wish to remain happy
and mentally healthy.

 

Pony is still pre-1.0, but the group is very active and competent.  I think
we should consider using it to build the VM.  Have a look.  Some videos for
your amusement and information:

 

 

https://www.youtube.com/watch?v=ODBd9S1jV2s

https://www.youtube.com/watch?v=u1JfYa413fY

https://www.youtube.com/watch?v=fNdnr1MUXp8

https://www.ponylang.io/

 

There are many others.  I mentioned the Pony concurrency architecture around
the holidays, but there was no interest from the list-not a good time
perhaps.

The tentative plan is to do what Google does with Flutter:  have the JIT in
support of the usual dynamicity a Smalltalker needs for rapid development;
and have AOT, fully optimized compiling for production or speed-related
reality checks, presumably needed less often during development.  There are
other possibilities.  

 

Anyone interested?   

 

I have some ideas for simplifying use of the six ref caps in the context of
Pharo/Smalltalk.  If this path is chosen, one must commit to strict
state-machine-based algorithm development, without exception.  This should
have happened anyway by now, broadly in the programming space, but didn't.
I'm working on a programming graphical tool and associated grammar (in VW)
that make state-machine development easy and attractive.  This , besides
efficient use of machine resources, is the other reason for pushing in this
direction.  

 

A Pony program is built from a net of asynchronously communicating actors.
You change the state of your program with asynchronous messaging between
actors.  There is no blocking--no mutexes or semaphores-and therefore no
wasted CPU cycles or mushrooming program complexity, as you try to use
mutexes in a fine-grained way (a very bad idea).  And as mentioned, there
are never deadlocks or data-races.  All cores on all CPUs stay busy, always,
until the program goes idle or exits.  The Pony group is also working on
extending the model to the network level, so that all machine nodes in the
network stay busy.  In the round, as a start, think of Pony as Erlang/OTP,
but much faster, with no legacy bugs, and provably no-deadlocking on
compile. 

 

The asynchronous actor model is the programming pattern that Kay had in mind
when he said "object-oriented."  It's the one I want to implement in Pharo.
The green threads are light, but don't efficiently use the cores, and a net
of VMs with their respective images still communicate too slowly.

 

I your time permits, please study Pony for a bit, before rejecting the idea
as too big a change in direction or too complicated.  Using Pony looks like
the ideal VM simplification strategy, if our aim is efficient use of
networks of machines, each with at least one CPU (often more), each, in
turn, with many cores (whose numbers are still increasing).  This pattern in
hardware probably won't be changing much, now that speeds are topping out.
Winning the performance game is therefore about efficiently using many cores
at once, without burdening the programmer.  I don't see a better way to do
this now than with Pony.

 

Thoughts and suggestions are welcome.

 

Shaping

 

 

 

 

> -Original Message-

> From: Pharo-users [ 
mailto:pharo-users-boun...@lists.pharo.org] On 

> Behalf Of N. Bouraqadi

> Sent: Tuesday, 28 January, 2020 12:18

> To: Any question about pharo is welcome <
 pharo-users@lists.pharo.org>

> Subject: [Pharo-users] Latest PharoJS Success Story

> 

> The latest PharoJS-powered smartphone app is now live.

> Development has been made using Pharo.

> Then, javascrip

[Pharo-users] [ANN] Pharo-Spreedsheet on GitHub

[Torsten Bergmann]

Hi,

I just moved "Spreadsheet" from SmalltalkHub 
(http://www.smalltalkhub.com/#!/~TorstenBergmann/Spreadsheet)
to a community owned location at GitHub 
("https://github.com/pharo-contributions/Pharo-Spreadsheet";).

If I remember correctly the project goes back to ancient Squeak times - but it 
was kept up to date
and is basically working. So if you want to write the next killer spreadsheet 
application in Pharo
then you might want to use this as a base.

Screenshot attached

Have fun
T. (aka astares)

Re: [Pharo-users] [ANN] Pharo-Spreedsheet on GitHub

[Guillermo Polito]

Thanks!

> El 3 abr 2020, a las 21:39, Torsten Bergmann  escribió:
> 
> Hi,
> 
> I just moved "Spreadsheet" from SmalltalkHub 
> (http://www.smalltalkhub.com/#!/~TorstenBergmann/Spreadsheet)
> to a community owned location at GitHub 
> ("https://github.com/pharo-contributions/Pharo-Spreadsheet";).
> 
> If I remember correctly the project goes back to ancient Squeak times - but 
> it was kept up to date
> and is basically working. So if you want to write the next killer spreadsheet 
> application in Pharo
> then you might want to use this as a base.
> 
> Screenshot attached
> 
> Have fun
> T. (aka astares)
> 
> 
> 
> 

Re: [Pharo-users] [ANN] Pharo-Spreedsheet on GitHub

[teso...@gmail.com]

Thanks, it is really cool!

On Fri, Apr 3, 2020 at 10:20 PM Guillermo Polito
 wrote:
>
> Thanks!
>
> > El 3 abr 2020, a las 21:39, Torsten Bergmann  escribió:
> >
> > Hi,
> >
> > I just moved "Spreadsheet" from SmalltalkHub 
> > (http://www.smalltalkhub.com/#!/~TorstenBergmann/Spreadsheet)
> > to a community owned location at GitHub 
> > ("https://github.com/pharo-contributions/Pharo-Spreadsheet";).
> >
> > If I remember correctly the project goes back to ancient Squeak times - but 
> > it was kept up to date
> > and is basically working. So if you want to write the next killer 
> > spreadsheet application in Pharo
> > then you might want to use this as a base.
> >
> > Screenshot attached
> >
> > Have fun
> > T. (aka astares)
> >
> >
> >
> > 
>
>


-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-users] [ANN] SuffixConditionals moved to GitHub

[Torsten Bergmann]

The quick port of the Suffix conditionals for Pharo moved from STHub
to GitHub now:

   https://github.com/astares/Pharo-SuffixConditionals

Update / fork on GH in case you use it.

Bye
T.

[Pharo-users] [ANN] TinyMCE for Seaside moved to GitHub

[Torsten Bergmann]

Seaside wrapper for Tiny MCE Editor moved to GitHub now too
including load instructions:

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

Screenshot and details to be found on the project page.

Have fun
T.

[Pharo-users] [ANN] Temple on GitHub

[Torsten Bergmann]

Need a very minimalistic template engine for Pharo to be able to embed 
expressions
in text? Then maybe the simple "Temple" project

  https://github.com/astares/Pharo-Temple

is useful for you.

Side note:
==
If this is just too minimalistic and you need more then check Norberts Mustache 
project:

  https://github.com/noha/mustache

Bye
T.