June 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] Pharo6 server deployment and no home directory

by Holger Freyther

> On 8. Jun 2017, at 23:16, Holger Freyther <holger(a)freyther.de> wrote: > > Hey Juraj! Hey! this will most likely block more people trying to deploy a headless Pharo6 image but I am not so sure how to properly fix it. > $ unset HOME > $ pharo ... > Error: Can't find the requested origin ... > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: $HOME is not set so cantFindOriginError will be executed. > UnixResolver>>home > [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home / '.config' ] XDG_CONFIG_DIR can not be found and then "self home" will be executed... > FileLocator(AbstractFileReference)>>exists (FileLocator preferences / '.config' / ...) resolve exists a.) Behave like unix and resolve $HOME to '' $ unset HOME $ echo $HOME/.config /.config self home / '.config' => '/.config' b.) FileLocator>>#exists If something can not be resolved, one can argue that it doesn't exist? So I wonder if the exception should be catched and false be returned? c.) ??? I don't see an obvious/good approach. Do you? holger

June 9, 2017

Re: [Pharo-dev] Seaside Control Panel crashing

by Max Leske

Hi Casimiro, Weâre aware of the issue and already have a fix in the works. Please report Seaside issues to the Seaside github repository (https://github.com/SeasideSt/Seaside <https://github.com/SeasideSt/Seaside>) or on the Seaside mailing list. Cheers, Max > On 8 Jun 2017, at 22:17, casimiro barreto <casimiro.barreto(a)gmail.com> wrote: > > Latest image, it crashes with 'KeyNotFound: key #NewListModel not found in SystemDictionary > > WAPharoServerAdapterSpecBrowser new -> WAPharoServerAdapterSpecBrowser initializeWidgets -> instantiateModels: -> Array pairsDo: -> WAPharoServerAdapterSpecBrowser instantiateModels -> createInstanceFor: -> resolveSymbol: -> SmalltalkImage at: #NewListModel -> SystemDictionary at: #NewListModel -> at:ifAbsent: -> at: [self errorKeyNotFound: #NewListModel ] -> errorKeyNotFound > > Nothing that cannot be solved by starting ZnServerAdaptor from workspace (playground...). > > -- > The information contained in this message is confidential and > intended to the recipients specified in the headers. If you received > this message by error, notify the sender immediately. The > unauthorized use, disclosure, copy or alteration of this message > are strictly forbidden and subjected to civil and criminal sanctions.

June 8, 2017

Seaside Control Panel crashing

by casimiro barreto

Latest image, it crashes with 'KeyNotFound: key #NewListModel not found in SystemDictionary WAPharoServerAdapterSpecBrowser new -> WAPharoServerAdapterSpecBrowser initializeWidgets -> instantiateModels: -> Array pairsDo: -> WAPharoServerAdapterSpecBrowser instantiateModels -> createInstanceFor: -> resolveSymbol: -> SmalltalkImage at: #NewListModel -> SystemDictionary at: #NewListModel -> at:ifAbsent: -> at: [self errorKeyNotFound: #NewListModel ] -> errorKeyNotFound Nothing that cannot be solved by starting ZnServerAdaptor from workspace (playground...). -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions.

June 8, 2017

Re: [Pharo-dev] remote development via VS Code

by phil＠highoctane.be

On Thu, Jun 8, 2017 at 5:45 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Dimitris, > > > On Jun 8, 2017, at 3:01 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > Can you be a bit more specific I have no clue what you talking about :D > > On Thu, Jun 8, 2017 at 11:33 AM philippe.back(a)highoctane.be < > philippe.back(a)gmail.com> wrote: > >> We need to open this up.. >> I want to expose the image using fuse on linux. >> > > Fuse, MacFuse and Dokan are all instances of "file system in user space" > systems that allow and program to function as a file system server, much > like NFS, over a socket. > > There systems define a wire format and a set of requests and responses > that cover the domain of file systems (listing directory contents, > creating, opening, reading, writing, closing and deleting files, etc). > > The program functioning as a server can therefore externalise any data it > so chooses as a file system. It is possible, for example, to make classes > appear as directories with methods as files within them, with subclasses as > sub directories, and hence the entire class hierarchy as a directory tree. > Writing a file could be mapped into recompiling or adding a method, etc. > > There are many things one could use this for, but one clear direction, > from the success of docker, is to make a Smalltalk image observable and > configurable by devops people without having to start up an image and > navigate an unfamiliar and foreign UI & IDE. Such a direction is probably > not well served by a naÃ¯ve mapping of classes and methods to directories > and files (what about global variables, what about doits, what about > Instantiation?) but the potential is there. > My basic idea is to: 1/ be able to drop binary resources in the image (including datasets) 2/ be able to edit those resources with native tools from the FS view (say, Gimp, or Vim ..) 3/ be able to edit classes and methods using vim on a server. 4/ be able to see vm and image parameters as files and be able to change them as needed (sysctl style) We need several logical locations in the filesystem like: /vm/ /environment/ /workspace/ws1/contents For workspace contents, it would do a doIt on write, possibly creating a contents.out It is a cool project :-) Phil > HTH > > Holidays coming... >> >> Phil >> >> Le 8 juin 2017 10:17, "Dimitris Chloupis" <kilon.alios(a)gmail.com> a >> Ã©crit : >> >>> problem is when you try to use a generic ide or an ide made for another >>> language is that you get a sub standard experience. For example pyDev is an >>> Eclipse extension that allows one to use Eclipse which is a predominantly >>> Java IDE for Python. I used that in the past now I use PyCharm a Python >>> exclusive IDE that is like nigh and day with PyDev. >>> >>> Pharo IDE has a lot of issues (auto completion being the worst for me) >>> but its after all tailor made for Pharo. IDE APIs by the way are very >>> common , especially for open source IDEs like Eclipse, Netbeans etc. So its >>> possible to connect pharo with a ton of IDEs out there and not particularly >>> hard , but there is little motivation to do so. >>> >>> On Thu, Jun 8, 2017 at 8:19 AM Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> I just bumped into Microsoft's MIT Licensed IDE "Visual Studio Code" >>>> that runs on OSX, Linux & Windows. What is interesting is their Debug >>>> Protocol for connecting to language specific debuggers. >>>> * https://code.visualstudio.com/docs/extensionAPI/api-debugging >>>> >>>> If I had time, it would be interesting (and super cool) to build a >>>> Debug Adaptor in Pharo >>>> * https://code.visualstudio.com/docs/extensionAPI/language-support >>>> as well as a Language Server Protocol provider >>>> * https://code.visualstudio.com/docs/extensionAPI/language-support >>>> Could make a good student project or two. The skills learnt and >>>> demonstrated would be quite marketable outside of the Pharo community. >>>> >>>> From a marketing perspective, it might be more palatable for existing >>>> Visual Studio users to install Pharo as an extension rather than install >>>> Pharo as a whole new IDE (i.e. Pharo) - a common complaint about Smalltalk >>>> in general. At a minimum there is the exposure gained from Microsoft's >>>> Extension Marketplace, with early adoptors trying out Pharo >>>> just-because-its-there. It also smashes that regular criticism of Smalltalk >>>> that it lives too much in its on isolated world. >>>> >>>> It might attract developers wanting to do polygot development, for >>>> example (just guessing that might be possible): >>>> * game development using Unity libraries for the game engine with >>>> Ronnie's minimal-vm embedded as the scripting language, and debugging both >>>> in parallel from a single environment >>>> * Pharo web server backend with Javascript frontend >>>> >>>> I vaguely wonder if it would be possible to make a Debug Adaptor that >>>> integrates VM & Image level debugging, transparently stepping from >>>> Smalltalk into the VM C code. That could be useful for FFI debugging, or >>>> developing low-level graphics interfaces that might break our internal IDE. >>>> >>>> Disclaimer: Like all my random ideas, its a bit vague and dreamy, but I >>>> had no concept of it yesterday, so just sharing the find to stimulate >>>> future ideas. >>>> >>>> cheers -ben >>>> >>>

June 8, 2017

Re: [Pharo-dev] remote development via VS Code

by Dimitris Chloupis

Thanks Eliot for the detailed explanation it makes a lot more sense now. I agree its very interesting. On Thu, Jun 8, 2017 at 6:46 PM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Dimitris, > > > On Jun 8, 2017, at 3:01 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > Can you be a bit more specific I have no clue what you talking about :D > > On Thu, Jun 8, 2017 at 11:33 AM philippe.back(a)highoctane.be < > philippe.back(a)gmail.com> wrote: > >> We need to open this up.. >> I want to expose the image using fuse on linux. >> > > Fuse, MacFuse and Dokan are all instances of "file system in user space" > systems that allow and program to function as a file system server, much > like NFS, over a socket. > > There systems define a wire format and a set of requests and responses > that cover the domain of file systems (listing directory contents, > creating, opening, reading, writing, closing and deleting files, etc). > > The program functioning as a server can therefore externalise any data it > so chooses as a file system. It is possible, for example, to make classes > appear as directories with methods as files within them, with subclasses as > sub directories, and hence the entire class hierarchy as a directory tree. > Writing a file could be mapped into recompiling or adding a method, etc. > > There are many things one could use this for, but one clear direction, > from the success of docker, is to make a Smalltalk image observable and > configurable by devops people without having to start up an image and > navigate an unfamiliar and foreign UI & IDE. Such a direction is probably > not well served by a naÃ¯ve mapping of classes and methods to directories > and files (what about global variables, what about doits, what about > Instantiation?) but the potential is there. > > HTH > > Holidays coming... >> >> Phil >> >> Le 8 juin 2017 10:17, "Dimitris Chloupis" <kilon.alios(a)gmail.com> a >> Ã©crit : >> >>> problem is when you try to use a generic ide or an ide made for another >>> language is that you get a sub standard experience. For example pyDev is an >>> Eclipse extension that allows one to use Eclipse which is a predominantly >>> Java IDE for Python. I used that in the past now I use PyCharm a Python >>> exclusive IDE that is like nigh and day with PyDev. >>> >>> Pharo IDE has a lot of issues (auto completion being the worst for me) >>> but its after all tailor made for Pharo. IDE APIs by the way are very >>> common , especially for open source IDEs like Eclipse, Netbeans etc. So its >>> possible to connect pharo with a ton of IDEs out there and not particularly >>> hard , but there is little motivation to do so. >>> >>> On Thu, Jun 8, 2017 at 8:19 AM Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> I just bumped into Microsoft's MIT Licensed IDE "Visual Studio Code" >>>> that runs on OSX, Linux & Windows. What is interesting is their Debug >>>> Protocol for connecting to language specific debuggers. >>>> * https://code.visualstudio.com/docs/extensionAPI/api-debugging >>>> >>>> If I had time, it would be interesting (and super cool) to build a >>>> Debug Adaptor in Pharo >>>> * https://code.visualstudio.com/docs/extensionAPI/language-support >>>> as well as a Language Server Protocol provider >>>> * https://code.visualstudio.com/docs/extensionAPI/language-support >>>> Could make a good student project or two. The skills learnt and >>>> demonstrated would be quite marketable outside of the Pharo community. >>>> >>>> From a marketing perspective, it might be more palatable for existing >>>> Visual Studio users to install Pharo as an extension rather than install >>>> Pharo as a whole new IDE (i.e. Pharo) - a common complaint about Smalltalk >>>> in general. At a minimum there is the exposure gained from Microsoft's >>>> Extension Marketplace, with early adoptors trying out Pharo >>>> just-because-its-there. It also smashes that regular criticism of Smalltalk >>>> that it lives too much in its on isolated world. >>>> >>>> It might attract developers wanting to do polygot development, for >>>> example (just guessing that might be possible): >>>> * game development using Unity libraries for the game engine with >>>> Ronnie's minimal-vm embedded as the scripting language, and debugging both >>>> in parallel from a single environment >>>> * Pharo web server backend with Javascript frontend >>>> >>>> I vaguely wonder if it would be possible to make a Debug Adaptor that >>>> integrates VM & Image level debugging, transparently stepping from >>>> Smalltalk into the VM C code. That could be useful for FFI debugging, or >>>> developing low-level graphics interfaces that might break our internal IDE. >>>> >>>> Disclaimer: Like all my random ideas, its a bit vague and dreamy, but I >>>> had no concept of it yesterday, so just sharing the find to stimulate >>>> future ideas. >>>> >>>> cheers -ben >>>> >>>

June 8, 2017

Re: [Pharo-dev] remote development via VS Code

by Eliot Miranda

Hi Dimitris, > On Jun 8, 2017, at 3:01 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Can you be a bit more specific I have no clue what you talking about :D > >> On Thu, Jun 8, 2017 at 11:33 AM philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: >> We need to open this up.. >> I want to expose the image using fuse on linux. Fuse, MacFuse and Dokan are all instances of "file system in user space" systems that allow and program to function as a file system server, much like NFS, over a socket. There systems define a wire format and a set of requests and responses that cover the domain of file systems (listing directory contents, creating, opening, reading, writing, closing and deleting files, etc). The program functioning as a server can therefore externalise any data it so chooses as a file system. It is possible, for example, to make classes appear as directories with methods as files within them, with subclasses as sub directories, and hence the entire class hierarchy as a directory tree. Writing a file could be mapped into recompiling or adding a method, etc. There are many things one could use this for, but one clear direction, from the success of docker, is to make a Smalltalk image observable and configurable by devops people without having to start up an image and navigate an unfamiliar and foreign UI & IDE. Such a direction is probably not well served by a naÃ¯ve mapping of classes and methods to directories and files (what about global variables, what about doits, what about Instantiation?) but the potential is there. HTH >> Holidays coming... >> >> Phil >> >> Le 8 juin 2017 10:17, "Dimitris Chloupis" <kilon.alios(a)gmail.com> a Ã©crit : >>> problem is when you try to use a generic ide or an ide made for another language is that you get a sub standard experience. For example pyDev is an Eclipse extension that allows one to use Eclipse which is a predominantly Java IDE for Python. I used that in the past now I use PyCharm a Python exclusive IDE that is like nigh and day with PyDev. >>> >>> Pharo IDE has a lot of issues (auto completion being the worst for me) but its after all tailor made for Pharo. IDE APIs by the way are very common , especially for open source IDEs like Eclipse, Netbeans etc. So its possible to connect pharo with a ton of IDEs out there and not particularly hard , but there is little motivation to do so. >>> >>>> On Thu, Jun 8, 2017 at 8:19 AM Ben Coman <btc(a)openinworld.com> wrote: >>>> I just bumped into Microsoft's MIT Licensed IDE "Visual Studio Code" that runs on OSX, Linux & Windows. What is interesting is their Debug Protocol for connecting to language specific debuggers. >>>> * https://code.visualstudio.com/docs/extensionAPI/api-debugging >>>> >>>> If I had time, it would be interesting (and super cool) to build a Debug Adaptor in Pharo >>>> * https://code.visualstudio.com/docs/extensionAPI/language-support >>>> as well as a Language Server Protocol provider >>>> * https://code.visualstudio.com/docs/extensionAPI/language-support >>>> Could make a good student project or two. The skills learnt and demonstrated would be quite marketable outside of the Pharo community. >>>> >>>> From a marketing perspective, it might be more palatable for existing Visual Studio users to install Pharo as an extension rather than install Pharo as a whole new IDE (i.e. Pharo) - a common complaint about Smalltalk in general. At a minimum there is the exposure gained from Microsoft's Extension Marketplace, with early adoptors trying out Pharo just-because-its-there. It also smashes that regular criticism of Smalltalk that it lives too much in its on isolated world. >>>> >>>> It might attract developers wanting to do polygot development, for example (just guessing that might be possible): >>>> * game development using Unity libraries for the game engine with Ronnie's minimal-vm embedded as the scripting language, and debugging both in parallel from a single environment >>>> * Pharo web server backend with Javascript frontend >>>> >>>> I vaguely wonder if it would be possible to make a Debug Adaptor that integrates VM & Image level debugging, transparently stepping from Smalltalk into the VM C code. That could be useful for FFI debugging, or developing low-level graphics interfaces that might break our internal IDE. >>>> >>>> Disclaimer: Like all my random ideas, its a bit vague and dreamy, but I had no concept of it yesterday, so just sharing the find to stimulate future ideas. >>>> >>>> cheers -ben

June 8, 2017

Re: [Pharo-dev] remote development via VS Code

by Eliot Miranda

Hi Luke, _,,,^..^,,,_ (phone) > On Jun 8, 2017, at 3:15 AM, Luke Gorrie <luke(a)snabb.co> wrote: > >> On 8 June 2017 at 07:18, Ben Coman <btc(a)openinworld.com> wrote: >> From a marketing perspective, it might be more palatable for existing Visual Studio users to install Pharo as an extension rather than install Pharo as a whole new IDE (i.e. Pharo) - a common complaint about Smalltalk in general. > > JFYI: I have a very new project called Studio that will use Pharo as the front-end for "add on" development tools. > > The notion is to have a UI based on Pharo/Glamor that presents a unified interface to a back-end built on many and various diagnostic tools (e.g. perf, wireshark, etc, depending on what is relevant to a given application.) > > The assumption is that people already have an editor, etc, but what they don't have is an easy way to create application-specific development and diagnostic tools. That's my situation, anyway, and I am initially the main target user here. > > Currently I am working towards teaching the Inspector to explore internal data structures in a tracing JIT. This will provide end-users with visibility into the way the JIT generates code (currently completely inscrutable) There is nothing inscrutable about the Cog JIT in the standard Pharo and Squeak VMs. Once the VMMaker.oscog package is loaded (and there's a script to build such an image in the image subdirrectory of the opensmalltalk/vm repository) one can either simulate execution of an entire image or use "in image compilation" to compile any single method in the host image to machine code. The JIT is written entirely in Smalltalk. Decompilation is derived from a processor/specific plugin but then decorated by Smalltalk code to produce the most easily read jutted code I've ever worked with. I don't see how this counts as at all inscrutable. > and make for easy cross-referencing with profilers and benchmarks. Sophie Kaleba is a GSoC intern working with ClÃ©ment Bera, and is extending the Cog VMProfiler with more information about the jutted code. Perhaps there's synergy here? > I am taking a semi-generic approach where the JIT will log raw C structs and then the Studio IDE will use DWARF debug information to import them for meaningful inspection ("gdb-style"). > > Link: https://github.com/studio/studio > > Cheers, > -Luke > >

June 8, 2017

Re: [Pharo-dev] remote development via VS Code

by Ben Coman

On Thu, Jun 8, 2017 at 6:15 PM, Luke Gorrie <luke(a)snabb.co> wrote: > On 8 June 2017 at 07:18, Ben Coman <btc(a)openinworld.com> wrote: > >> From a marketing perspective, it might be more palatable for existing >> Visual Studio users to install Pharo as an extension rather than install >> Pharo as a whole new IDE (i.e. Pharo) - a common complaint about Smalltalk >> in general. >> > > JFYI: I have a very new project called Studio that will use Pharo as the > front-end for "add on" development tools. > > The notion is to have a UI based on Pharo/Glamor that presents a unified > interface to a back-end built on many and various diagnostic tools (e.g. > perf, wireshark, etc, depending on what is relevant to a given application.) > Having a Pharo front end to wireshark coupled to Roassal for graphing would be super-super cool. > > The assumption is that people already have an editor, etc, but what they > don't have is an easy way to create application-specific development and > diagnostic tools. That's my situation, anyway, and I am initially the main > target user here. > Always the best kind of target user. > > Currently I am working towards teaching the Inspector to explore internal > data structures in a tracing JIT. > I presume this is for LuaJIT that Snabbu uses? > This will provide end-users with visibility into the way the JIT generates > code (currently completely inscrutable) and make for easy cross-referencing > with profilers and benchmarks. I am taking a semi-generic approach where > the JIT will log raw C structs and then the Studio IDE will use DWARF debug > information to import them for meaningful inspection ("gdb-style"). > That will be impressive. It would be nice if the DWARF stuff can be separated. I'm sure that could be useful sometime elsewhere. cheers -ben

June 8, 2017

Re: [Pharo-dev] Heise

by Ben Coman

Very cool. It reads well through google translate too. cheers -ben 2017-06-08 16:59 GMT+08:00 Christian Haider < christian.haider(a)smalltalked-visuals.com>: > You made it on Heise News! > > https://www.heise.de/newsticker/meldung/Programmiersprache-Pharo-6- > bekommt-64-Bit-Versionen-und-neue-Tools-3737593.html > > > > Congrats, > > Christian >

June 8, 2017

Re: [Pharo-dev] remote development via VS Code

by Luke Gorrie

On 8 June 2017 at 07:18, Ben Coman <btc(a)openinworld.com> wrote: > From a marketing perspective, it might be more palatable for existing > Visual Studio users to install Pharo as an extension rather than install > Pharo as a whole new IDE (i.e. Pharo) - a common complaint about Smalltalk > in general. > JFYI: I have a very new project called Studio that will use Pharo as the front-end for "add on" development tools. The notion is to have a UI based on Pharo/Glamor that presents a unified interface to a back-end built on many and various diagnostic tools (e.g. perf, wireshark, etc, depending on what is relevant to a given application.) The assumption is that people already have an editor, etc, but what they don't have is an easy way to create application-specific development and diagnostic tools. That's my situation, anyway, and I am initially the main target user here. Currently I am working towards teaching the Inspector to explore internal data structures in a tracing JIT. This will provide end-users with visibility into the way the JIT generates code (currently completely inscrutable) and make for easy cross-referencing with profilers and benchmarks. I am taking a semi-generic approach where the JIT will log raw C structs and then the Studio IDE will use DWARF debug information to import them for meaningful inspection ("gdb-style"). Link: https://github.com/studio/studio Cheers, -Luke

June 8, 2017