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

Re: [Pharo-users] Custom URI scheme for Pharo

by Dimitris Chloupis

Probably it was your thread but as I said you can make a "hack" and overlay a system GUI over Pharo GUI This way you can view the PDF, "inside" Pharo. I think it is even possile to get the handle of the Pharo window and directly affect it to embed a PDF viewer. The second solution is better because you want have to wory about Pharo window resizing as the PDF will be trully embeded inisde the Pharo window instead of overlayed. I am willing to bet you can avoid the multiple windows anooyance in some way on another without making your head explode. Unless its not a priority for you. Looks great, well done mate. Keep the creative juices flowing ;) On Thu, Oct 12, 2017 at 2:02 AM Manuel Leuenberger <leuenberger(a)inf.unibe.ch> wrote: > Sounds like a nice setup you got there :). > > I want to integrate documents displayed in the system viewer, as they > cannot be displayed within Pharo (Web, PDF, â¦). So hyperlinking is the only > way I see to get something close. I created a little demo where I injected > hyperlinks in a PDF like âpharo://click?whatever=youwant'. When you click > them, a little Objective-C app catches the OS event and forwards it to an > HTTP server running in Pharo. So I can do things like this: > > https://youtu.be/CR_scZSDf3s > > On 11 Oct 2017, at 00:24, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I think I remember this disussed before. > By talking with Pharo I assume here about another program talking to Pharo > ? Possible not wrriten in Pharo ? > > If thats the case then you can use whatever IPC works better for your > needs. If the communication will be remotely I recommend sockets, for fast > local communication I recommend shared memory. They are both very mature > technologies , very reliable and cross platform. > > Now on the URI protocol, I think that will depend what you want to > achieve. Any string will be easy to parse with Pharo's regex and trigger > the approriate methods. Pharo also have Annoucements, think of it as an > event system that awaits to be triggered by an event, usually a Pharo event > but I see no reason why it cant listen to external events either. > > I do not think you will need a middle application , a servel client > relation shipe should be more than enough. > > With my Atlas bridge which is a Pharo library that allows you to use > Python libraries I did a neat trick with Pharo that it already communicated > with Python via sockets, sending python commands but also Python could > communicate back errors , then Pharo would trigger the debugger, display > the python error inside the Pharo debugger and the debugger would pop up on > the exact pharo command that send the faulty python code. You could then > change the pharo command on the spot and it was resent and python continued > like the error never happened to retain the all important live coding > workflow. > > I created a tiny protocol to difirentia incoming messages talking about > errors from the ones returning python varriable values. Something stupid > like "pythonError: blah blah" but it got the job done > > > > On Tue, Oct 10, 2017 at 10:07 PM Manuel Leuenberger < > leuenberger(a)inf.unibe.ch> wrote: > >> Hi, >> >> Is there any support from the VM/Application package to add custom URI >> schemes to listen to from within Pharo? I would like to have a hyperlink >> like âpharo://send?data=fancypantsâ in an arbitrary document that, when >> clicked, switches to Pharo and calls a hook I can register. Could someone >> give me a hint how to achieve that, or do I have to build a little bridge >> application that handles the scheme registration and talks with Pharo >> through another channel? Currently, I only need this for OS X. >> >> Cheers, >> Manuel >> >> > >

Oct. 12, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by stephan

On 12-10-17 08:30, Markus Stumptner wrote: > Just to lead this back to the original question.Â What you say is > undoubtedly true.Â It is not, however, necessarily something that a > beginner will understand or be able to share in. That is a very important point. It also explains a lot of why we are missing certain things that developers coming from other environments take for granted: they simply provide less value to experienced smalltalkers. And that is indeed a barrier to entry. I remember sharply my first looking at squeak, and just not understanding how I could create a new class or method in a browser. Another was that I have been programming in seaside for a year without using senders and implementers. Pair programming for an hour with Philippe Marschall showed me so much invisible/hidden functionality. Other (mainstream) environments don't provide the immediate feedback of navigating, inspecting and manipulating the whole environment, and therefore newcomers have no appropriate expectations (internal model), and are clueless on what they are able to do in Pharo. Combined with the lack of systematic visual clues and the high density of the class library that makes it not easy to learn. Stephan

Oct. 12, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

That's definetly not a wrong view point, but neither is python's , its all about context. Who you are ? What you want do ? What live coding means to you ? How you want to use it ? How much you want to use it? etc If you want to do Pharo coding the pharo way , then Pharo is your No1 choice, but if you want to Pharo coding the python way , Python is your No1 choice and etc. Thus I never pick sides in language wars , I am participating merely to find things I do not know. Like I just found about become in the VM list, though I still wait for enumarion of classes and reified frame stacks to be explained as well. I am here to learn as much I am here to teach. Well ok , more likely to learn :D For example messages vs method calls. What happens if method calls are executing by reference, does that make them cross message territory?. Meaning you use a name to hide the reference to an object of a method. You change the reference to the method but without changing the name of the call. Or what happens when you extend the MethodObject to cross message territory, is this still "bastardised OOP" or Alan's Keay great regret of naming it "OOP" ? OR is it smalltalkish OOP in python , or is it something more ? Those question do fascinate me.Languages are so fluid, its like clay in our hands. We live in very exciting times. On Thu, Oct 12, 2017 at 11:08 AM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > 2017-10-12 9:28 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> >> >> >>> This is what Smalltalk gives you for free. >>> >> Sorrry for being rude but I wll use the two usually heavily annoying >> word, at least for me :D >> >> It depends >> >> See there is a problem for Python here. Ideology. >> >> The zen of python has been both a joke a serious mantra in the python >> world . Its a joke because its obviously oversimplify decision making in >> such a complex subject as language designe but is serious because it >> clearly illustrates the philosophy of its creator, Guido van Rossum. >> >> https://www.python.org/dev/peps/pep-0020/ >> >> Guido is not any less of a rock star to Pythoners than Alan Kay is for >> Smalltalkers. The zen has become so popular that is even included in python >> implementation and can be fetched as the link says using the "import this" >> in any implementation of Python. It's the very sould of python as messages >> and objects are the very soul of Smalltalk. >> >> So the problem here is that a live coding enviroment brakes the second >> rule. "explicit is better than implicit". Because live coding in Pharo and >> Smaltalk is about replacing old instances with new while keeping the state >> it non the less an implicit behavior and especially become is a no go >> scenario for python because not only replaces references to an object it >> also breaks the references to the other object. Of course the old object is >> garbage collected and RIP. Python follows this rule very strictly. >> >> Thus means that not only that Python will not offer a live coding >> enviroment in the future as the basis of its implementation . It means it >> does not want to. It may offer it as part of its extensive library. >> >> That also leads us to the inescapable conclusion that nothing comes free, >> everything has a cost. Because there will be scenarios you dont want to >> lose your old instances or not affect them at all and instead affect only >> the classes or maybe you dont even want to do that and want to do something >> else. >> > > > Hm, we have our own Pharo Zen, which includes a > Explicit is better than implicit. > So we are violating our own (zen)rules :) > > in my point of view, live or interactive coding has not much to do with > explicit or implicit program code. > >

Oct. 12, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Nicolai Hess

2017-10-12 9:28 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > > > >> This is what Smalltalk gives you for free. >> > Sorrry for being rude but I wll use the two usually heavily annoying word, > at least for me :D > > It depends > > See there is a problem for Python here. Ideology. > > The zen of python has been both a joke a serious mantra in the python > world . Its a joke because its obviously oversimplify decision making in > such a complex subject as language designe but is serious because it > clearly illustrates the philosophy of its creator, Guido van Rossum. > > https://www.python.org/dev/peps/pep-0020/ > > Guido is not any less of a rock star to Pythoners than Alan Kay is for > Smalltalkers. The zen has become so popular that is even included in python > implementation and can be fetched as the link says using the "import this" > in any implementation of Python. It's the very sould of python as messages > and objects are the very soul of Smalltalk. > > So the problem here is that a live coding enviroment brakes the second > rule. "explicit is better than implicit". Because live coding in Pharo and > Smaltalk is about replacing old instances with new while keeping the state > it non the less an implicit behavior and especially become is a no go > scenario for python because not only replaces references to an object it > also breaks the references to the other object. Of course the old object is > garbage collected and RIP. Python follows this rule very strictly. > > Thus means that not only that Python will not offer a live coding > enviroment in the future as the basis of its implementation . It means it > does not want to. It may offer it as part of its extensive library. > > That also leads us to the inescapable conclusion that nothing comes free, > everything has a cost. Because there will be scenarios you dont want to > lose your old instances or not affect them at all and instead affect only > the classes or maybe you dont even want to do that and want to do something > else. > Hm, we have our own Pharo Zen, which includes a Explicit is better than implicit. So we are violating our own (zen)rules :) in my point of view, live or interactive coding has not much to do with explicit or implicit program code.

Oct. 12, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

"one of the reasons that Smalltalk historically has been view as insular, living in its own world avoid using non-Smalltalk libraries - because the lose of live coding here is a big impact." I would not say that Smalltalk is viewed as insular. I would say that Smallalk is not viewed at all period. Pharo wise the people who introduced to Pharo have been impressed by it. The same way most Pharoers prefer pharo libraries to c libraries via UFFI , applies to python coders as well. You think a python coder is eager to leave the comforts of his language, think again. In both communities its user with either C experience or motivated to learn C for personal reasons that use the FFIs or other means to import C code. Is it an accident that 99% of C wrapped code libraries for Python are existing C projects ? Some existing for decades and predating Python. A pure Python developers will be as unlikely to use the FFI as a Pharo developer, and by developers I mean users not the people who actually develop Pharo. So no there is nothing wrong with Smalltalk and Smallalk works with C just fine. Python's C API gained quickly reputation among the C people of being easy to us so Python became the go to language for scripting C. This is also why Python offered embeding, because back then Python was slooowwww. This led Guido to claim that Python may be a great choice for scripting C project but choice for replacing high performance code. He did not even intended the language to target anything else than scriptin. Nonetheless that did not stop the community from pop up like mushrooms high performance libraries to that extend that nowdays Python is regarded as the second best choice for high performance computing after C/C++ which if you think about it sounds kinda insane but non the less wrapped optimised C python libraries can easily outperform non optimised C/C++ code. An example being the emarashing truth that Python strings are faster than C++ strings which forces C++ coders to use an external library that optimised them called Boost. So the real irony is that back then embeding Python was recommended, nowdays embdeding Python is frown upon. Instead now its recommended to brake your C project to a library wrapped for Python and import it to Python. Its fascinating to see something that started so humble become so ambitious but that is true power of the community and this is also the true power of Pharo. You can let this misconceptions get in the way and think small like "Python/Pharo cannot do this, or is hard to do" or you can shut up (something I find hard to do) and just do it. As I said , we use only 0.0000001% of the potential of any language out there.

Oct. 12, 2017

Re: [Pharo-users] Custom URI scheme for Pharo

by Manuel Leuenberger

Sure, a system call out would be nicest way to register a handler. Unfortunately, registering custom URI schemes seems to be completely different on every platform, as well as how they receive an activation event. OS X uses a plist, Windows a registry entry, for Linux depends on the distro. So I went for a minimal solution. But it should be doable to provide a platform-aware package that takes case of the installation. > On 12 Oct 2017, at 09:34, Norbert Hartl <norbert(a)hartl.name> wrote: > > Ok, I see. Building a native app and interfacing it from pharo is the most reliable version. I was just thinking that having a system call out it might be easier to make it cross-platform. I would be interested to have that available for all platforms. > > Norbert > > Am 12.10.2017 um 09:20 schrieb Manuel Leuenberger <leuenberger(a)inf.unibe.ch <mailto:leuenberger@inf.unibe.ch>>: > >> That's what I did. Only I used a native Objective-C app, as it provides a simple API to register to the events and will even be started if it's not running yet. >> >> Am 12.10.2017 08:50 schrieb Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>>: >> I think all you need is to do a system call out to the OS in order to register your scheme. For Mac OS it would be sonething like >> >> >> https://superuser.com/questions/548119/how-do-i-configure-custom-url-handle… <https://superuser.com/questions/548119/how-do-i-configure-custom-url-handle…> >> >> And then you can see if it is what you want. Custom handlers associate a url scheme to an application binary. Iâm not sure you can use an image with it. So I would register a shell script and handle the adoption in the script. >> >> Does that help? >> >> Norbert >> >> Am 10.10.2017 um 21:06 schrieb Manuel Leuenberger <leuenberger(a)inf.unibe.ch <mailto:leuenberger@inf.unibe.ch>>: >> >> Hi, >> >> Is there any support from the VM/Application package to add custom URI schemes to listen to from within Pharo? I would like to have a hyperlink like âpharo://send?data=fancypantsâ in an arbitrary document that, when clicked, switches to Pharo and calls a hook I can register. Could someone give me a hint how to achieve that, or do I have to build a little bridge application that handles the scheme registration and talks with Pharo through another channel? Currently, I only need this for OS X. >> >> Cheers, >> Manuel >> >>

Oct. 12, 2017

Re: [Pharo-users] [Ann] PharoLauncher v1.0.1 released!

by Christophe Demarey

Hi Vitor, > Le 11 oct. 2017 Ã 13:44, Vitor Medina Cruz <vitormcruz(a)gmail.com> a Ã©crit : > > Hi Christophe, > > Yes, but: > 1- I canât execute it if I donât have administrative rights > ok. That the point I missed. I think I will add a zip file with PharoLauncher for windows for user like you not having admin rights. > âââI have tried with the provided link. Before I get to the installation directory choice, windows prompt me an error telling me I must be an admin. It is probably some windows policy for all exe files, I know it is possible to bypass this as some applications do (Intellij for example), but it is usually easier to provide a zip; > > > <image.png> > > 2- 7-Zip can open this executable as it were a zip file, thatâs how I manage to install Pharo Launcher. I need to think on the best way to handle that. Regards, Christophe.

Oct. 12, 2017

Re: [Pharo-users] Custom URI scheme for Pharo

by Norbert Hartl

Ok, I see. Building a native app and interfacing it from pharo is the most reliable version. I was just thinking that having a system call out it might be easier to make it cross-platform. I would be interested to have that available for all platforms. Norbert > Am 12.10.2017 um 09:20 schrieb Manuel Leuenberger <leuenberger(a)inf.unibe.ch>: > > That's what I did. Only I used a native Objective-C app, as it provides a simple API to register to the events and will even be started if it's not running yet. > > Am 12.10.2017 08:50 schrieb Norbert Hartl <norbert(a)hartl.name>: > I think all you need is to do a system call out to the OS in order to register your scheme. For Mac OS it would be sonething like > > > https://superuser.com/questions/548119/how-do-i-configure-custom-url-handle… > > And then you can see if it is what you want. Custom handlers associate a url scheme to an application binary. Iâm not sure you can use an image with it. So I would register a shell script and handle the adoption in the script. > > Does that help? > > Norbert > > Am 10.10.2017 um 21:06 schrieb Manuel Leuenberger <leuenberger(a)inf.unibe.ch>: > > Hi, > > Is there any support from the VM/Application package to add custom URI schemes to listen to from within Pharo? I would like to have a hyperlink like âpharo://send?data=fancypantsâ in an arbitrary document that, when clicked, switches to Pharo and calls a hook I can register. Could someone give me a hint how to achieve that, or do I have to build a little bridge application that handles the scheme registration and talks with Pharo through another channel? Currently, I only need this for OS X. > > Cheers, > Manuel > >

Oct. 12, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

> This is what Smalltalk gives you for free. > Sorrry for being rude but I wll use the two usually heavily annoying word, at least for me :D It depends See there is a problem for Python here. Ideology. The zen of python has been both a joke a serious mantra in the python world . Its a joke because its obviously oversimplify decision making in such a complex subject as language designe but is serious because it clearly illustrates the philosophy of its creator, Guido van Rossum. https://www.python.org/dev/peps/pep-0020/ Guido is not any less of a rock star to Pythoners than Alan Kay is for Smalltalkers. The zen has become so popular that is even included in python implementation and can be fetched as the link says using the "import this" in any implementation of Python. It's the very sould of python as messages and objects are the very soul of Smalltalk. So the problem here is that a live coding enviroment brakes the second rule. "explicit is better than implicit". Because live coding in Pharo and Smaltalk is about replacing old instances with new while keeping the state it non the less an implicit behavior and especially become is a no go scenario for python because not only replaces references to an object it also breaks the references to the other object. Of course the old object is garbage collected and RIP. Python follows this rule very strictly. Thus means that not only that Python will not offer a live coding enviroment in the future as the basis of its implementation . It means it does not want to. It may offer it as part of its extensive library. That also leads us to the inescapable conclusion that nothing comes free, everything has a cost. Because there will be scenarios you dont want to lose your old instances or not affect them at all and instead affect only the classes or maybe you dont even want to do that and want to do something else. > So while Python has the flexibility for you to program such a system > yourself, you don't get it for free like Smalltalk. > > >> So it does have a wide application. Python can give you back the >> references to and from an object (via gc module) but the problem is that >> when an object is created its already referenced by many internal stuff so >> it can get messy soon. >> > > Smalltalk handles this for free. You need #become: > https://gbracha.blogspot.com.au/2009/07/miracle-of-become.html > Note one of the comments links to user code that apparently does the same > thing in Python. But again this is Python "allows" you to, not "Python" > gives it to you, but it could be good enough for you. > > First the python example is not an actual become the way I understand it, because not only it does not change the references to the object , it exchanges only the variables not the methods http://wargle.blogspot.gr/2009/07/smalltalks-become-in-python.html __CLASS__ is reference to the class object. __DICT__ is a reference to the instance object dictionary contains basically the names of the variables but not references to the methods themselves . Which means this wont work for live coding. His example works because both classes share the same methods with same code in them but we know this is the polar opposite of live coding. You can get references to the modified methods using this code my_class_ref = (globals()[self.__class__.__name__]) found_methods=[eval("my_class_ref()." + entry,{'my_class_ref':my_class_ref}) for entry in dir(my_class_ref()) if eval("type(my_class_ref()." + entry + ").__name__",{'my_class_ref':my_class_ref}) == 'method'] Globals is used to fetch the reference to the class object. eval is used because names are passed as strings of course and basically eval executes a string as a collection of python commands and returns its value. In this case the value is a reference to an object, a method object. Dir returns all names , including both variables and methods, instance and class, including all superclasses. You do then something similar to get the old methods , and then you iterate checking the names and replacing the references with simple assignments. You end up with a become that is I would say around , if I brake down the list comprehension to multiple lines, 20 lines of code. It wont be still a Smalltalk become but it will support live coding and live replacement of instance objects. > Plus Python is not exactly a high performance language , >> > > We now have this for improved performance... > https://hal.inria.fr/hal-01152610/file/partialReadBarrier.pdf > > Here come the two ugly words "it depends" See what the python becomes does is essentially better than the smalltalk becomes. I know its hard to not throw tomatoes at me but if you take a closer look at the Elito's paper you linked you will see why. Python solution really becomes an object to another because its swaps its contents and not the entity of the object, this includes variables and methods and the class it points to. By entity here I mean its place in memory and by you I mean the person implementing the VM. In Smalltalk becomes is not really become but rather replaceReferences , because it brakes the references to the object and then replace them with references to another object. Unfortunately this creates problems because you have to find to references to the objects and that comes with a cost if thousands of things reference it. Hence why Eliot had to optimise this. But python solution has no cost because you dont have to change the references to the object. And references to the members of an object (variables and methods) have to pass through the reference to the object itself. So python in this cases does not have to optimise,because it deals with a lot less references.. Smalltalk has to. Why Smalltalk does it this way, I do not know , this is VM territory and clearly Eliot outranks me to a great degree on the subject of VM design but I am sure there is a technical reason. > unless you use third party libraries focusing on performance (basically C >> libraries wrapped for Python). >> > > And how does such C libraries impact your live coding? Its not longer > turtles all the way down (or its turtles walking off a cliff) > Of course, the same applies for FFI with Pharo, and one of the reasons > that Smalltalk historically has been view as insular, living in its own > world avoid using non-Smalltalk libraries - because the lose of live coding > here is a big impact. > > cheers -ben > > Sorry I cannot resist :D It depends Technically speaking your are wrong not only for Python but also for Pharo too. The reason being that even in the case of imported c functions they are wrapped inside objects. So it is indeed turtles all the way down. At least to the function level. The arguments passed to the c functions itself are also objects, the access to the memory also objects, pointers are also objects. C data types also object. Of course you need VM primitives to make the actual calls but those are wrapped into objects. So yes the room is full of turtles and there is no escape for you :D Python goes an extra step with its Python C API. This is an API used to build a DLL that is compatibe with Python. Essentially Python then can import this DLL as if it was a python source code file and use it as such. Most of the Python third party libraries use this approach. Cython also uses this approach too. The API forces you to use PyObject which is a C function that wraps a C function around a Python object. So when you access it from Python its now an object. Also remember that in Python , python functions are object too. So there is no escape. I have no idea how Pharo VM does this, I know it supports plugins in a similar function and I suspect that it forces you to wrap then in Smalltalk objects at least at bytecode level but no clue if that is the actual case. Again the experts can jump in and enlighten us. Of course wrapping the C function to be called as an object does not mean that you will wrap all the functions called by the C function. If those C functions are not meant to be used by the user then they wont be objects but they will also not be accessible. Always talking about Python C API. Talking about FFI, whether Pharo (UFFI) or Python (ctypes) there is no way around object creation that I am aware of. So you cannot avoid objects even if you want to. Of couse those object does not necessarily mean they offer you all your usual comfort , they may come with some small letter disclaimers but then we go back to the never ending "it depends" rabbit hole. > > >> In my case its easy to do because I care about live coding my own project >> and do not care about code outside of it, because I wont be changing it >> anyway. But if I had to do this the Pharo way , providing a full live >> enviroment it would be easy because I would have to find a mechanism to >> accomodate for tons of Python code that does not follow live coding >> standards by a long margin. So my goal is not to come up with full blown >> live coding enviroment like Pharo does, that is simply not possible because >> there is like a ton of python code out there and I am sure there so many >> scenarios that live coding in python can go wrong that I am not even aware >> of. But if live code is only for my code and my code alone , I dont think I >> will have any major issues. Afterall even when I use Pharo I use live >> coding strictly for my code and rarely touch the enviroment with the >> exception of once messing with UI theme classes. >> >> But then again I am so new to this that at any point I may come up for a >> solution about this too, who knows :) >> >> On Wed, Oct 11, 2017 at 7:05 PM Pierce Ng <pierce(a)samadhiweb.com> wrote: >> >>> On Sat, Oct 07, 2017 at 01:41:17AM +0000, Dimitris Chloupis wrote: >>> > execution. Hence live coding, the Python VM replaces objects lively. >>> Python >>> > can also compile any size of code including individual methods. >>> > That happens with one line of code importlib.reload(mymodule) >>> >>> AFAIK in Python when you modify and reload source, existing instances >>> are not >>> "reshaped" to the modified code. Not live enough. Of course with Python >>> objects >>> it is easy to add per-instance inst-vars, but still this needs to be >>> scripted >>> and doesn't come free with the programming environment. >>> >>> Pierce >>> >>>

Oct. 12, 2017

Re: [Pharo-users] Custom URI scheme for Pharo

by Manuel Leuenberger

Oct. 12, 2017