remote development via VS Code
Locked
 
|
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 as well as a Language Server Protocol provider 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 |
Re: remote development via VS Code
|
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 <[hidden email]> wrote:
|
Re: remote development via VS Code
|
|
We need to open this up.. I want to expose the image using fuse on linux. Holidays coming... Phil Le 8 juin 2017 10:17, "Dimitris Chloupis" <[hidden email]> a écrit :
|
Re: remote development via VS Code
|
|
Can you be a bit more specific I have no clue what you talking about :D
|
Re: remote development via VS Code
|
|
In reply to this post by Ben Coman
On 8 June 2017 at 07:18, Ben Coman <[hidden email]> wrote:
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"). Cheers, -Luke |
|
|
On Thu, Jun 8, 2017 at 6:15 PM, Luke Gorrie <[hidden email]> wrote:
Having a Pharo front end to wireshark coupled to Roassal for graphing would be super-super cool.
Always the best kind of target user.
I presume this is for LuaJIT that Snabbu uses?
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 |
Re: remote development via VS Code
|
|
In reply to this post by Luke Gorrie
Hi Luke,
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.
|
Re: remote development via VS Code
|
|
In reply to this post by kilon.alios
Hi Dimitris,
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
|
Re: remote development via VS Code
|
|
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 <[hidden email]> wrote:
|
Re: remote development via VS Code
|
|
In reply to this post by Eliot Miranda-2
On Thu, Jun 8, 2017 at 5:45 PM, Eliot Miranda <[hidden email]> wrote:
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
|
Re: remote development via VS Code
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
On 8 June 2017 at 17:30, Eliot Miranda <[hidden email]> wrote:
Sounds lovely. I am working with LuaJIT. I have half a dozen significant technical problems to solve before I am anywhere close to helping mere mortals to understand the tracing JIT and use it effectively. My interest in Pharo is to build development tools for my application, which is network equipment for ISPs written in LuaJIT with a little assembler. |
Re: remote development via VS Code
|
|
In reply to this post by Ben Coman
On 8 June 2017 at 15:07, Ben Coman <[hidden email]> wrote:
Short answer is yes. Long answer is that it is for RaptorJIT, which is the fork of LuaJIT where I am moving from diagnostics by introspection (Lua code running inside the VM) to by inspection (external Pharo/Nix tools that deeply understand the VM.) Ongoing hacking here: https://github.com/raptorjit/raptorjit/pull/63 Once it works the question will be whether to migrate Snabb to RaptorJIT or port the functionality back to LuaJIT.
I am finding it an interesting experience to write an application that is half Pharo (frontend) and half Nix (backend). For each piece of functionality the question is, how much should be done in the frontend vs the backend? For visualizing the JIT I could on the one hand do everything in the frontend with Pharo code to parse DWARF files, etc, or on the other hand I could do everything in the backend with Pharo simply displaying PNG files produced by Nix. Current trade-off is that Nix will produce a JSON summary of the DWARF type information and then Pharo will use that to decode the logged binary data structures via the GT Inspector. and when I say "Nix" I really mean the whole Nix ecosystem that includes basically every program and programming language. So I am able to freely mix shell, awk, perl, python, R, etc, and still keep things under control. That's the hypothesis anyway. Here is a PR showing the current Frankenstein DWARF backend if you're curious: https://github.com/studio/studio/pull/14 |
|
|
In reply to this post by Eliot Miranda-2
On Thursday 08 June 2017 09:15 PM, Eliot Miranda wrote:
> 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. FUSE is really useful for passive stores like zip, iso or tgz but not for suspended live object graph like an image. The toughest part here is not the mounting and name resolution but the semantic mapping between nodes and live objects. I have a different suggestion that I feel is more 'Smalltalkish'. It would be easier for us to build an object server thread into the VM to serve live objects in the image as a file hierarchy. It allows a finer control of object graph to filetree mapping. This encapsulates object implementation details in a single place (object manager) and respects platform-neutrality. There is already a precedence in sysfs of Linux. It shows a live tree of device and drivers object graph - subsystems, buses, devices, their drivers and events. The code is under 1500 lines [1] because it leverages ramfs for name resolution and just has the semantic functions for just four concepts - directory, file, group and mount. It uses special filenames like 'uevents' to pass events between userspace and kernel (equivalent to user processes and vm plugins in our case). The VM needs to have: a) a network responder (to listen and translate requests to paths (ordered collection of nodes), b) a name resolver to resolve paths to a name and name to a special object c) a semantic getter/setter to interpret these special objects. So you could have: /globals/<name>/value /classes -> /globals/classes/ /classes/Morph/instances/oop1/value, sizeInMemory etc. /objects -> /classes/Object/instances/ /Undefined/doIt /Undefined/printIt Instances don't comes with names one but they do have a unique id (oop) which can be mapped to a file (say oop%d). Indexed variables can be managed as 'group'. [1] http://elixir.free-electrons.com/linux/latest/source/fs/sysfs Regards .. Subbu |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |