May 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] XMLHTMLParser Entity Handling oddity

by monty

This should be fixed now. Thanks for the bug report. > Sent: Wednesday, May 03, 2017 at 4:44 PM > From: "Udo Schneider" <udo.schneider(a)homeaddress.de> > To: pharo-users(a)lists.pharo.org > Subject: [Pharo-users] XMLHTMLParser Entity Handling oddity > > All, > > I'm hitting an interesting issue with XMLHTMLParser and I'm not even > sure if this is a bug or intended behaviour. Given an HTML Entity in a > String it's resolved or quoted depending on the tag (header or section tag): > > doc := XMLHTMLParser parse: > '<html><head><title>Ã</title></head><body>Ã</body></html>'. > (doc findElementNamed: 'title') contentString. "'Ã'" > (doc findElementNamed: 'body') contentString. "'Ã'" > > In my understanding and according to > https://www.w3.org/TR/html401/struct/global.html#h-7.4.2 Entities in the > title tag are allowed and should IMHO be resolved. > > So both should return 'Ã' in this case. > > Any pointers? > > CU, > > Udo > > >

May 5, 2017

Re: [Pharo-users] Smalltalk syntactic coloration in Spec's TextModel

by Julien Delplanque

Thanks, it works perfectly. Julien On 04/05/17 13:11, Nicolai Hess wrote: > 2017-05-04 12:53 GMT+02:00 Julien Delplanque <julien(a)tamere.eu>: > >> Thanks, it works. >> >> Another question: Is it possible to manage the fact that the >> code displayed is a method? (ie not having the selector and >> instance variables causing the syntactic coloration to be >> red) >> > Yes, setting the behavior (class of the method): > > TextModel new > isForSmalltalkCode: true; > text: (Collection>>#anyOne) sourceCode; > aboutToStyle: true; > behavior: (Collection>>#anyOne) methodClass; > openWithSpec > > >> Thanks in advance, >> >> Julien >> >> >> >> On 03/05/17 17:09, Nicolai Hess wrote: >> >>> 2017-05-03 16:57 GMT+02:00 Julien Delplanque <julien(a)tamere.eu>: >>> >>> Hello, >>>> I looked in the mailing list archive but did not found an answer. >>>> >>>> Is there any way to have Smalltalk syntactic coloration in a TextModel >>>> without having to put efforts in it? >>>> >>>> I mean, if I do: >>>> >>>> TextModel new >>>> isForSmalltalkCode: true; >>>> text: (Collection>>#any) sourceCode; >>>> openWithSpec >>>> >>>> The text displayed is black. >>>> >>>> Thanks in advance, >>>> >>>> Julien >>>> >>>> >>>> >>>> Hi, >>> you need to add >>> aboutToStyle:true >>> >>> >>> >>> TextModel new >>> isForSmalltalkCode: true; >>> text: (Collection>>#anyOne) sourceCode; >>> aboutToStyle: true; >>> openWithSpec >>> >>> >>

May 4, 2017

Re: [Pharo-users] [ANN] git migration tool

by Thierry Goubier

Nice tool ! A good way to release some of the pressure on performance of the git layers, thanks Peter! Thierry 2017-05-04 14:32 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > With Iceberg knocking on the door, migration from SmalltalkHub to > Git(Hub/Lab/...) has become relevant once more. > > And that's why I wrote git-migration tool https://github.com/ > peteruhnak/git-migration to help you move on to greener pastures. > > Among other things described in the too-long-didn't read README: > > the tool will generate git-fast-import (a special format for fast git > imports) file that can be easily and quickly applied on your git repository. > All commits are preserved in their proper order, and merges (commits with > multiple parents) are also converted to git merges. > > So far I've tested it on my custom intentionally broken repository, and > PolyMath. > > PolyMath has 784 commits in 74 packages; it took Pharo about 3 minutes to > process all SmalltalkHub commits and generate 87MB file; git then imported > the file in less than a second. > > > (Git history of PolyMath in GitKraken) > > the tool also provides you with a bunch of visualizations that can help > you analyze your SmalltakHub history and investigate problems. > > > (trees of all packages in the PolyMath repository) > > More things could be desired (e.g. even better performance), so feel free > to open issues, ideally with pull requests. ;) > > Peter >

May 4, 2017

Re: [Pharo-users] [ANN] git migration tool

by Pavel Krivanek

Great tool! Thank you very much, Peter. -- Pavel 2017-05-04 14:32 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > With Iceberg knocking on the door, migration from SmalltalkHub to > Git(Hub/Lab/...) has become relevant once more. > > And that's why I wrote git-migration tool https://github.com/ > peteruhnak/git-migration to help you move on to greener pastures. > > Among other things described in the too-long-didn't read README: > > the tool will generate git-fast-import (a special format for fast git > imports) file that can be easily and quickly applied on your git repository. > All commits are preserved in their proper order, and merges (commits with > multiple parents) are also converted to git merges. > > So far I've tested it on my custom intentionally broken repository, and > PolyMath. > > PolyMath has 784 commits in 74 packages; it took Pharo about 3 minutes to > process all SmalltalkHub commits and generate 87MB file; git then imported > the file in less than a second. > > > (Git history of PolyMath in GitKraken) > > the tool also provides you with a bunch of visualizations that can help > you analyze your SmalltakHub history and investigate problems. > > > (trees of all packages in the PolyMath repository) > > More things could be desired (e.g. even better performance), so feel free > to open issues, ideally with pull requests. ;) > > Peter >

May 4, 2017

[ANN] git migration tool

by Peter UhnÃ¡k

With Iceberg knocking on the door, migration from SmalltalkHub to Git(Hub/Lab/...) has become relevant once more. And that's why I wrote git-migration tool https://github.com/peteruhnak/git-migration to help you move on to greener pastures. Among other things described in the too-long-didn't read README: the tool will generate git-fast-import (a special format for fast git imports) file that can be easily and quickly applied on your git repository. All commits are preserved in their proper order, and merges (commits with multiple parents) are also converted to git merges. So far I've tested it on my custom intentionally broken repository, and PolyMath. PolyMath has 784 commits in 74 packages; it took Pharo about 3 minutes to process all SmalltalkHub commits and generate 87MB file; git then imported the file in less than a second. (Git history of PolyMath in GitKraken) the tool also provides you with a bunch of visualizations that can help you analyze your SmalltakHub history and investigate problems. (trees of all packages in the PolyMath repository) More things could be desired (e.g. even better performance), so feel free to open issues, ideally with pull requests. ;) Peter

May 4, 2017

Re: [Pharo-users] Out of image IDE

by Dimitris Chloupis

<Begin stupid proud moment> Been there done that <End stupid proud moment> I have two Pharo libraries available through the Package Browser. The first is *Atlas*, it allows Pharo to use python code. This happening by Atlas sending python commands as string via a socket (super unsecure I know but I use it only locally) , the communication is two way, Pharo sends commands , python sends data if pharo ask them. I manage to create a pharo python syntax, very basic parsing and super simple syntax (full support of python syntax is not necessary because I intended only to use python libraries not develop python code). The lib is made to work locally but its architecture is open enough that should be easy to use also remotely. *Pros:* 1) Ability to use pharo syntax that is converted to python syntax. The trick here through a nasty hack on MessageNotUnderstood Atlas is able to call python libraries directly with pharo syntax with zero need for wrapping 2) Socket mechanism is already installed in all OS , so there is nothing to install if you have pharo and python 3 3) There is support for live coding this happens because Atlas sends Python errors back to Pharo and triggers the Pharo debugger. It then stops execution at Python side, it does not allow the application to end because it uses a python exception to capture python errors , but it waits till the next command from Pharo 4) There is a basic parser for python objects to pharo objects that can be used as an example 5) It works with most Python libraries apart from ones depending on thread and async 6) Library is open enough that can be used for remote or locally connecting to anything and anywhere *Cons:* 1) The pharo to python syntax is super limited to method and functions call and variable assignments. But there is nothing stop it from been improved 2) Sockets are Slowwwwwwwwwww . They offer awesome cross platform compatibility but it comes with performance cost. Local communication usually goes under on millisecond but still slow I would say anywhere between 10-100 times. So no long loops. This can be avoided by making the loop entirely in python and this way make much less connections. Atlas support sending python code as a string 3) Live coding works but I have not heavily tested so it will be probably limited because unlike Pharo , Python is not an out of the box live coding language 4) Types parser is super basic and offers close to zero support its there only as an example. I did not bother with it because the types I receive from python are just numbers, floats and strings. 5) It had issues once with a library that used threads. 6) It does not come with a communication protocol , it sends only python commands as strings thus its unsecured but nowadays encryption is super easy so it should not be a problem adding it as a features. The second one is *CPPBridge *this one uses Shared Memory Mapped Files to use an API inside a C++ executable. Its like embedding Pharo but without embedding it. Shared memory is a functionality of the OS, its pretty standard and supported by all major OS, it allows two or more processes to have an area of memory that can access. There are access rights that can be setup but in my case its send so both sides can read and write. *Pros: * 1) The most important , its nuclear fast. This happens because shared memory uses the lowest level of memory management from OS 2) Because everything is saved into a file and because you are not required to call a save actions , the OS does this for you, it becomes impossible to lose data. Even in the case of crash and believe I had to crash Pharo a ton of times to make this work, the data is never lost. 3) Its super reliable , memory mapped files is how DLLs and other dynamic libraries work , so its a feature that is heavily used by the OS 4) Because its really low level , it allows you to compact memory down to the last bit , giving you full control over memory management, You can replicate the data to Pharo side if you want but its not necessary 5) Its allow you to use Pharo as if it was embeded inside a C++ executable 6) Because it gives you access to memory and because a C++ executable is statically compiled its super safe and it would require very low level hacking. Also being strictly local helps *Cons:* 1) This is the most important for you, it does not work remotely, this is 100% local but of course it could be combined with sockets 2) Its quite technical because it demands a basic understanding of the OS way of handling memory 3) continuing from the previous points, its manual memory management which means you have to be extra careful what you do because its easy to crass. I tried with the API to make it less easy but still , its not safe. 4) It wont automagically copy data from the shared memory to Pharo but the good news is that unlike a socket you do not need to wait for the other end to open to access your data since it is stored in a file 5) You will have to handle yourself synchronizations issue, generally speaking corruption cannot happen because it handled by the OS BUT it could mess up the order of your data if both sides are not in agreement whos is writing and when. So that is how I control Pharo mainly locally but as I said the first would be very easily converted to remote connection. Also besides me a couple of other people used it without any major issues other than the usual bug. On Thu, May 4, 2017 at 12:13 PM Luke Gorrie <luke(a)snabb.co> wrote: > On 4 May 2017 at 05:26, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> Forwarding message stuck on Nabble (probably the author is not subscribed >> to >> the list)... >> >> sigipa wrote >> > Hello All, >> > >> > I've been playing with Pharo off and on for a few years now. I have >> > thought a lot about where and how I could potentially use it. I have an >> > idea about how I would really like it to work, but up to now I haven't >> had >> > the chance to pursue it. I think I may even have had a discussion about >> it >> > with someone on this list at some point. Due to some recent changes in >> my >> > situation, It looks I may be at a point that I can look into things more >> > seriously. > > > I am in a possibly similar situation. > > I have also been wanting better tools for my application development work > for some years now, and this year it has finally bubbled up to the top of > my priority list. My applications are not based on Pharo but I want to use > Pharo for the tooling. > > The basic design I am following is a frontend/backend split. The frontend > is Pharo with the "Moldable Tools" concept i.e. spotter, inspector, Roassal > visualizations, etc. The backend is nix i.e. integrating diverse tools > (profilers, debuggers, protocol analyzers, statistical models, physical > hardware resources, etc.) > > I am building network equipment and mostly need diagnostic tools for > profiling and troubleshooting issues after they have occurred. So my > emphasis is not so much live coding as "what interesting observations can > we make about these 1000 core dump files from various environments and > software versions?" > > I hope that the design will be practical and that the project will grow to > support other people's applications too. Just now it is very early days. > Link: https://github.com/studio/studio > > Cheers, > -Luke > > >

May 4, 2017

Re: [Pharo-users] How to listen for source code change in the image ?

by Steven Costiou

Thanks :) Le 2017-05-04 13:55, Thierry Goubier a Ã©crit : > You need to register to the system announcer singleton to receive the MethodModified event, with, for example: > > SystemAnnouncer uniqueInstance when: MethodModified send: #aMethodUpdated: to: self > > Regards, > > Thierry > > 2017-05-04 13:40 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > >> Hi, >> >> where should i look at if i want a class of mine to be notified of any source code change in the image ? >> >> Specifically i want to know if anything changed about a method (or its ast method node), anything that could happen like a refactoring operation or a source code change. >> >> Steven.

May 4, 2017

Re: [Pharo-users] How to listen for source code change in the image ?

by Thierry Goubier

You need to register to the system announcer singleton to receive the MethodModified event, with, for example: SystemAnnouncer uniqueInstance when: MethodModified send: #aMethodUpdated: to: self Regards, Thierry 2017-05-04 13:40 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > Hi, > > where should i look at if i want a class of mine to be notified of any > source code change in the image ? > > Specifically i want to know if anything changed about a method (or its ast > method node), anything that could happen like a refactoring operation or a > source code change. > > Steven. >

May 4, 2017

Re: [Pharo-users] A Logo Proposal for Smalltalk

by horrido

Tudor Girba-2 wrote > I find it fascinating how the discussion about Smalltalk dialects happen > in a Pharo mailing list :). It's no mystery. Pharo has the biggest and most active Smalltalk user community, so you can't beat it for community outreach. Also, Pharo seems to be closely allied with ESUG. Discussions here may percolate through to other user groups. -- View this message in context: http://forum.world.st/A-Logo-Proposal-for-Smalltalk-tp4945122p4945561.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 4, 2017

How to listen for source code change in the image ?

by Steven Costiou

Hi, where should i look at if i want a class of mine to be notified of any source code change in the image ? Specifically i want to know if anything changed about a method (or its ast method node), anything that could happen like a refactoring operation or a source code change. Steven.

May 4, 2017