- Pharo-users - lists.pharo.org

JS charting widgets in PharoJS

by Shaping

Does anyone have experience with JS financial charting widgets like https://app.fintatech.com/demo in PharoJS? Shaping

Oct. 7, 2019

Pharo: Git and GUI speed; JS widget reuse in PharoJS

by Shaping

Are we sure that Git is really the best way to go? Yes, it's everywhere, but its representation in Iceberg seems awkward or incomplete. I've been able to crash several Pharo VMs with routine repo operations. This is why I backed away recently from Pharo--that and the mush (see below). The other thing that keeps me planted firmly in VW is the sheer speed of it. Pharo looks generally much better, but it's mushy, and that's a problem. VW is not. Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms. I'm seeing 100, 150, and 200 ms regularly in Pharo. It's too mushy, and that slows the mind. Any developer understands this, whether he talks about it or not. So I'm wondering when the Pharo GUI will snap as well as VW. One thing that would help is to give the option of button-down selection in Settings, but even this is not enough. I tweaked the code, and made it so, but still was not happy: not enough snap and crackle. You may have acclimated and not noticed the problem, depending on how long you've been using Pharo. Otherwise, I like the Pharo DSL idea for JS. I'm working with VW's AppeX now. I'm not sure I like it, but that's mostly about finding JS to be one of the worst languages ever invented. However, the reuse and leverage is there, but at what cost in poor reading/thinking? I'm on the fence with AppeX, but will probably give it a chance. How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we don't want to read JS if we don't have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not. Shaping

Oct. 7, 2019

Re: [Pharo-users] Installing PharoJS

by Shaping

This is a git problem on Windows only with nested directories resulting in long path names, not a problem of Pharo directly. Usually you should not have it since most projects should already be in Tonel format now (Tonel saves some space on the path length). Dont know if PharoJS and all dependencies are already in Tonel format. I guess it is because your image already is in "c:/Users/Crypto/Documents/Pharo/images/PharoJS in 7.0.64-bit" and then the usual "pharo-local/iceberg/..." gets added when cloning through iceberg. Depending on project this leads to a long path for git. Several options you could try to resolve this: ============================ a) Install Pharo Launcher on a short path like "c:\pharo" (instead of the long user directory default). When you then download for instance a Pharo 7 64 bit image using Pharo Launcher just use a short name for the image itself like "PJS7-64". This usually reduces the path size already. I wanted to install the Launcher in Program Files and had a permissions problems I needed to fix. It was doable, but I did not want to continue the practice with each new install of Launcher. So I gave up and accepted the default in the user folder, which I do not want. I donât want my images and VMs in the usual âuser documentsâ area. I want that on another drive (RAID). The installer and launcher seem rigid. Not to broaden the topic, but does anyone know how to install Launcher and then the new images anywhere without any problems? I think the main problem was Launcher and the default location for all Pharo git files. I prefer also to have my own separate collection of Git projects on another drive. I donât want anything on the system drive but exes, dlls and related config files that I can be replaced with an installer. All else, my images and Git repos, are placed elsewhere, and the installer seems awkward if I use this pattern. If someone has a favorite scheme that supports this pattern, please do share. b) If you have a local git client already (like the one from <https://git-scm.com[https:/git-scm.com/download/win> https://git-scm.com[https://git-scm.com/download/win]) then configure your local git like: git config --system core.longpaths true The command worked. However, I got the same walkback with the Monticello baseline load. Should this work? Does one need always to load the baseline first? Why would the entire PharoJS repo not be enough? My default assumption would be to assume the PharoJS repo has all I need. I have enough trouble with Iceberg (the GUI seem deeply wrong and confused like the designer canât decided whether to mirror Git (repo menu item) or wrap and improve it [the rest of the GUI]) that I try to avoid using it. I use GitKraken to load the repo, then I point to it with Iceberg, but the options given for reconciling the cloned repo with whatâs in the image donât seem to work. and clone the project from commandline on a short path: cd c:\pharo git clone <https://github.com/bouraqadi/PharoJS.git> https://github.com/bouraqadi/PharoJS.git You can then use Iceberg to connect to it via "Add" -> "Import from existing clone" and load the baseline from there. I did this with the PharoJS repo I cloned earlier with GitKraken: I get proxiesForGlobals and state Not Loaded. c) Go to "Pharo" -> "Settings Browser", select "Tools" -> "Software Configuration Management" -> "Iceberg" and choose "Share repositories between images". Then set the "Location for shared repositories" to a short path name like "c:\pharo". Dont forget to hit enter. Okay, but I find the whole notion of sharing repos between images something that should just work and not be special like this. I just want to connect the one image to the one repo and have it work coherently. Why does Settings introduce the idea of sharing the repo between images. Iâm trying to do the more basic thing and it doesnât work. (Thereâs no file dialog for Default Code Subdirectory.) You can double check by inspecting: IceLibgitRepository sharedRepositoriesLocationString inspect Itâs correct. in a Playground. Iceberg will use this directory to clone project - using a short path will shorten the overall path length for the cloned PharoJS project. Some of this might help - if not use Ubuntu or OSX ;) Same Not Loaded state results. Thanks. Shaping

Oct. 7, 2019

Re: [Pharo-users] Installing PharoJS

by Shaping

File name or extension is too long, but length is 118, well under 260. Soâ¦. Failed to stat file? Is that supposed to be âstartâ? From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Christopher Fuhrman Sent: Sunday, 6 October, 2019 11:34 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Installing PharoJS Hello, The screenshot cuts off the error, but it may be the problem with file names that are too long in libgit2. It's a controversial problem in libgit2 for at least six years. https://github.com/libgit2/libgit2/issues/1899 Hitting this problem is what drove me to install WSL on Windows 10 and use Pharo that way, effectively not using Windows 10 for Pharo. Other workarounds exist, including a short image name in the launcher, putting image folders at the root level, telling Pharo to put iceberg repos in a fixed directory closer to the root, etc. You want a way to prevent a Pharo file path that's longer than 260 chars. Cheers, Cris On Sun, Oct 6, 2019, 10:52 Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: All you need to do is evaluating the following expression in a playground. I suggest you do it in a fresh image. Metacello new baseline: 'PharoJS'; repository: 'github://bouraqadi/PharoJS'; load That was one of the tests mentioned. See the screenshot below. The problem seems Git-related: Shaping On 6 Oct 2019, at 14:49, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: Hi. Can someone explain exactly how to install the latest version of PharoJS, and verify that the proedure really works? I've tried: 1) cloning the PharoJS repo in Pharo 8.0 with Iceberg, and get a Not Loaded final state for the repo. 2) loading into Pharo 7, 6.1, and 5 using Metacello new baseline: 'PharoJS'; repository: 'github://bouraqadi/PharoJS'; load All tries fail with a walkback. 3) loading into Pharo 4.0 using Gofer it smalltalkhubUser: 'noury' project: 'PharoJS'; addPackage: #ConfigurationOfPharoJS ; loadStable. The walkback here mentions missing dependency RBGlobalNode. Suggestions are welcome. Thanks. Shaping

Oct. 7, 2019

Re: [Pharo-users] Installing PharoJS

by Torsten Bergmann

Hi Shaping, Â This is a git problem on Windows only withÂ nested directories resulting in long path names, not a problem of Pharo directly.Â Â Usually you should not have it since most projects should already be in Tonel format now (Tonel saves some space on the path length). Dont know if PharoJS and all dependenciesÂ are already in Tonel format. I guess it is because your image already is in "c:/Users/Crypto/Documents/Pharo/images/PharoJS in 7.0.64-bit" and then the usual "pharo-local/iceberg/..." gets added when cloning through iceberg. Depending on project this leads to a long pathÂ for git. Â Several options you could try to resolve this: ============================ Â a) Install Pharo Launcher on a short path like "c:\pharo" (instead of the long user directory default). Â Â Â When you then download for instance a Pharo 7 64 bit image using Pharo Launcher just use a short name Â Â Â for the image itself like "PJS7-64". This usually reduces the path size already. Â b)Â If you have a local git client already (like the one from https://git-scm.com[https://git-scm.com/download/win]) then configure your local git like: Â Â Â Â Â git config --system core.longpaths true Â and clone the project from commandline on a short path: Â cd c:\pharo Â git clone https://github.com/bouraqadi/PharoJS.git Â Â You can then use Iceberg to connect to it via "Add" -> "Import from existing clone" and load the baseline from there. c) Go to "Pharo" -> "Settings Browser", select "Tools" -> "Software Configuration Management" -> "Iceberg" Â Â and choose "Share repositories between images". Then set the "Location for shared repositories" to a Â Â short path name like "c:\pharo". Dont forget to hit enter.Â Â Â You can double check by inspecting:Â Â Â Â Â Â Â IceLibgitRepository sharedRepositoriesLocationString inspect Â Â in a Playground. Iceberg will use this directoryÂ to clone project - using a short path will shorten theÂ Â Â overall path length for the cloned PharoJS project. Â Some of this might help - if not use Ubuntu or OSX ;) Â Bye T.

Oct. 6, 2019

Re: [Pharo-users] Installing PharoJS

by Christopher Fuhrman

Hello, The screenshot cuts off the error, but it may be the problem with file names that are too long in libgit2. It's a controversial problem in libgit2 for at least six years. https://github.com/libgit2/libgit2/issues/1899 Hitting this problem is what drove me to install WSL on Windows 10 and use Pharo that way, effectively not using Windows 10 for Pharo. Other workarounds exist, including a short image name in the launcher, putting image folders at the root level, telling Pharo to put iceberg repos in a fixed directory closer to the root, etc. You want a way to prevent a Pharo file path that's longer than 260 chars. Cheers, Cris On Sun, Oct 6, 2019, 10:52 Shaping <shaping(a)uurda.org> wrote: > All you need to do is evaluating the following expression in a playground. > > I suggest you do it in a fresh image. > > > > Metacello new > baseline: 'PharoJS'; > repository: 'github://bouraqadi/PharoJS'; > load > > > > That was one of the tests mentioned. See the screenshot below. The > problem seems Git-related: > > > > > > > > > > Shaping > > > > On 6 Oct 2019, at 14:49, Shaping <shaping(a)uurda.org> wrote: > > > > Hi. > > Can someone explain exactly how to install the latest version of PharoJS, > and verify that the proedure really works? > > I've tried: > > 1) cloning the PharoJS repo in Pharo 8.0 with Iceberg, and get a Not Loaded > final state for the repo. > 2) loading into Pharo 7, 6.1, and 5 using > > Metacello new > baseline: 'PharoJS'; > repository: 'github://bouraqadi/PharoJS'; > load > > All tries fail with a walkback. > > 3) loading into Pharo 4.0 using > > Gofer it > smalltalkhubUser: 'noury' project: 'PharoJS'; > addPackage: #ConfigurationOfPharoJS ; > loadStable. > > The walkback here mentions missing dependency RBGlobalNode. > > > Suggestions are welcome. > > Thanks. > > > Shaping > > > > > > >

Oct. 6, 2019

Re: [Pharo-users] Installing PharoJS

by Shaping

All you need to do is evaluating the following expression in a playground. I suggest you do it in a fresh image. Metacello new baseline: 'PharoJS'; repository: 'github://bouraqadi/PharoJS'; load That was one of the tests mentioned. See the screenshot below. The problem seems Git-related: Shaping On 6 Oct 2019, at 14:49, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: Hi. Can someone explain exactly how to install the latest version of PharoJS, and verify that the proedure really works? I've tried: 1) cloning the PharoJS repo in Pharo 8.0 with Iceberg, and get a Not Loaded final state for the repo. 2) loading into Pharo 7, 6.1, and 5 using Metacello new baseline: 'PharoJS'; repository: 'github://bouraqadi/PharoJS'; load All tries fail with a walkback. 3) loading into Pharo 4.0 using Gofer it smalltalkhubUser: 'noury' project: 'PharoJS'; addPackage: #ConfigurationOfPharoJS ; loadStable. The walkback here mentions missing dependency RBGlobalNode. Suggestions are welcome. Thanks. Shaping

Oct. 6, 2019

Re: [Pharo-users] Installing PharoJS

by Noury Bouraqadi

Hi, Cloning a repo (for any project) is not enough. You need to load the baseline. All you need to do is evaluating the following expression in a playground. I suggest you do it in a fresh image. > Metacello new > baseline: 'PharoJS'; > repository: 'github://bouraqadi/PharoJS'; > load > This is the officiel way of loading PharoJS as stated in Github and pharojs.org <http://pharojs.org/>. It should work just fine but ONLY with Pharo 7. Noury > On 6 Oct 2019, at 14:49, Shaping <shaping(a)uurda.org> wrote: > > Hi. > > Can someone explain exactly how to install the latest version of PharoJS, > and verify that the proedure really works? > > I've tried: > > 1) cloning the PharoJS repo in Pharo 8.0 with Iceberg, and get a Not Loaded > final state for the repo. > 2) loading into Pharo 7, 6.1, and 5 using > > Metacello new > baseline: 'PharoJS'; > repository: 'github://bouraqadi/PharoJS'; > load > > All tries fail with a walkback. > > 3) loading into Pharo 4.0 using > > Gofer it > smalltalkhubUser: 'noury' project: 'PharoJS'; > addPackage: #ConfigurationOfPharoJS ; > loadStable. > > The walkback here mentions missing dependency RBGlobalNode. > > > Suggestions are welcome. > > Thanks. > > > Shaping > > > > > >

Oct. 6, 2019

Installing PharoJS

by Shaping

Hi. Can someone explain exactly how to install the latest version of PharoJS, and verify that the proedure really works? I've tried: 1) cloning the PharoJS repo in Pharo 8.0 with Iceberg, and get a Not Loaded final state for the repo. 2) loading into Pharo 7, 6.1, and 5 using Metacello new baseline: 'PharoJS'; repository: 'github://bouraqadi/PharoJS'; load All tries fail with a walkback. 3) loading into Pharo 4.0 using Gofer it smalltalkhubUser: 'noury' project: 'PharoJS'; addPackage: #ConfigurationOfPharoJS ; loadStable. The walkback here mentions missing dependency RBGlobalNode. Suggestions are welcome. Thanks. Shaping

Oct. 6, 2019

Re: [Pharo-users] Iceberg: relative file path to repository

by eftomi

Posting a question to this list brings the inspiration by itself :-) When the location of repository is set like this: (IceLibgitRepository registry) do: [ :reg | (reg name = 'myRepo') ifTrue: [ reg location: ('pharo-local/iceberg/myRepo' asFileReference) ] ] the path is taken as relative: File @ pharo-local\iceberg\myRepo and not as absolute: File @ C:\Users\eftomi\PHARO\images\Pharo 8.0 - Glorp\pharo-local\iceberg\myRepo Iceberg is OK with it, as it seems. Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2019