April 2020 - Pharo-users - lists.pharo.org

Help! Iceberg just stopped working!

by Russ Whaley

I did a commit last night to GitHub - I checked, it's there. Today when I tried to load iceberg I get the attached error (see screenshot). The libraries from last night's commit/push are still there - but Iceberg says it can't find them... and refuses to load so that I could maybe delete the reference and then add it back (something I have to do quite often as the iceberg/github connection gets disconnected every couple of days or so). Can anyone tell me where to start looking? Where it says on the error - that it can't find my files at a certain location... the 2nd screenshot - is those files at that location!... Thanks! Russ -- Russ Whaley whaley.russ(a)gmail.com

April 3, 2020

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

by tesonep＠gmail.com

Thanks, it is really cool! On Fri, Apr 3, 2020 at 10:20 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Thanks! > > > El 3 abr 2020, a las 21:39, Torsten Bergmann <astares(a)gmx.de> 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) > > > > > > > > <screenshot.png> > > -- Pablo Tesone. tesonep(a)gmail.com

April 3, 2020

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

by Guillermo Polito

Thanks! > El 3 abr 2020, a las 21:39, Torsten Bergmann <astares(a)gmx.de> 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) > > > > <screenshot.png>

April 3, 2020

[ANN] Pharo-Spreedsheet on GitHub

by 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)

April 3, 2020

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

by 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-bounces@lists.pharo.org> mailto:pharo-users-bounces@lists.pharo.org] On > Behalf Of N. Bouraqadi > Sent: Tuesday, 28 January, 2020 12:18 > To: Any question about pharo is welcome < <mailto:pharo-users@lists.pharo.org> pharo-users(a)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, 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/> https://nootrix.com/projects/brain-treats-app/ > > Noury > >

April 3, 2020

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

by Guillermo Polito

Hi Renaud, > El 3 abr 2020, a las 16:27, Renaud de Villemeur <renaud.devillemeur(a)tuta.io> 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… <http://catalog.pharo.org/catalog/note-for-developers?_s=bHk4XDBcH9mb0muM&_k…> > 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 guillermopolito(a)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 <http://squeaksource.com/> or http://ss3.gemstone.com <http://ss3.gemstone.com/> > > Those wanting to migrate to git, Peter Uhnakâs git migration tool (https://github.com/peteruhnak/git-migration <https://github.com/peteruhnak/git-migration>) automates monticello to git migration in tonel format. > > Cheers, > Guille on behalf of the RMoD team >

April 3, 2020

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

by PBKResearch

Hello Michal Many thanks for your comprehensive explanation. I am using these translations just as a vehicle to get the text of my incoming e-mails into Pharo, so the conditional comments have no relevance to my use and are just clutter. I shall therefore continue preprocessing the received HTML to turn them into legal comments. I have found that they come with various forms of âifâ, so the rewriting just turns â<![â into ââ. I do this with String>>replaceAll:with:, but it might be interesting to write a PetitParser job to eliminate them completely. We can only hope that MS will sometime realise the meaning of the word âdeprecatedâ; I am using the latest Outlook in Office 365, and these forms are only relevant to long-dead versions of IE. Probably you are right that XMLHTMLParser should handle them tidily, but whether it is worth the effort depends on how often they turn up in the wild. It appears I may be the only person so far to have hit this, just because of my combination of Outlook with Pharo. I shanât be clamouring for any quick change. Thanks again for your help. Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Michal Balda Sent: 03 April 2020 16:45 To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] How should XMLHTMLParser handle strange HTML? 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> 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: <![if !supportLists]> <![endif]> 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

April 3, 2020

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

by 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> https://en.wikipedia.org/wiki/Conditional_comment <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: > > <![if !supportLists]> > > <![endif]> > > 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 >

April 3, 2020

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

by Renaud de Villemeur

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… Will it be deprecated as well ? Thanks Renaud Apr. 3, 2020, 05:55 by guillermopolito(a)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 <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 >

April 3, 2020

Re: [Pharo-users] Latest PharoJS Success Story

by Noury Bouraqadi

Hi Shaping, > On 3 Apr 2020, at 06:09, Shaping <shaping(a)uurda.org> 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-bounces@lists.pharo.org] On Behalf Of > N. Bouraqadi > Sent: Tuesday, 28 January, 2020 12:18 > To: Any question about pharo is welcome <pharo-users(a)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, 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 > >

April 3, 2020