Administrator
|
I noticed sometimes sthub hangs forever on Chrome (Version 34.0.1847.116 on Mavericks), but if I open it alongside in Safari, it loads fine...
Cheers,
Sean |
Sean P. DeNigris writes: > I noticed sometimes sthub hangs forever on Chrome (Version 34.0.1847.116 on > Mavericks), but if I open it alongside in Safari, it loads fine... Does the page load but stays without content, or is it another issue? Nico > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Smalltalk-Hub-on-Chrome-tp4755788.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- Nicolas Petton http://nicolas-petton.fr |
Administrator
|
It looks like this:
Cheers,
Sean |
This is why we should not have accepted to get it built in
Javascript.... because after you have to maintain. Stef Le 23/4/14 à 04:16, Sean P. DeNigris a écrit : > It looks like this: > > <http://forum.world.st/file/n4755918/Screenshot_2014-04-22_22.png> > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Smalltalk-Hub-on-Chrome-tp4755788p4755918.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > |
In reply to this post by Sean P. DeNigris
> On 22 Apr 2014, at 16:43, Sean P. DeNigris <[hidden email]> wrote: > > I noticed sometimes sthub hangs forever on Chrome (Version 34.0.1847.116 on > Mavericks), but if I open it alongside in Safari, it loads fine… For what it’s worth, this happens in Safari too from time to time. I don’t think it is browser related. Cheers, Max > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Smalltalk-Hub-on-Chrome-tp4755788.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
> This is why we should not have accepted to get it built in Javascript.... If you want it to be interactive, there's no choice but to use javascript… well at least until WebAssembly comes out. What I've noticed when STHub got stuck like this for me (it happened many times in the past), is that one of the loaded resources 404ed, so the load never finished. After I've cleaned the cache it worked fine again. So I think this was a server problem (Zinc?) that didn't properly return files. Peter On Sun, Jun 26, 2016 at 10:31 AM, Max Leske <[hidden email]> wrote:
|
Isnt WebAssembly Javascript anyway ? I dont see how you can avoid javascript in the browserOn Sun, Jun 26, 2016 at 12:36 PM Peter Uhnák <[hidden email]> wrote:
|
ah ok i stand corrected, just google it On Sun, Jun 26, 2016 at 1:48 PM Dimitris Chloupis <[hidden email]> wrote:
|
exactly :) On Sun, Jun 26, 2016 at 12:53 PM, Dimitris Chloupis <[hidden email]> wrote:
|
In reply to this post by Peter Uhnak
But my point is that - we do not need it (not a the cost to have a complete stack
to maintain) - and for the really few palces where you need you can use Jquery!
Stef Le 26/6/16 à 11:34, Peter Uhnák a
écrit :
|
Torsten made a replacement for smalltalkhub fully on seaside+bootstrap…
honestly, I want to get rid off sthub, but I imagine it will be around for some time… so maybe we need to consider deprecate the amber client and use a full-pharo version. Some remarks: - I don’t know if is finished
- I know it was not compatible at voyage level, so some work needs to be done there... Esteban
|
Torsten what is the state of your solution?
|
Administrator
|
Is it worth it to take another trip down this road of rolling-our-own source code repo? Whatever we create, we accept the responsibility to maintain, and with GitHub's social coding features, BitBucket for free private repo hosting, and all the advances in Pharo-git integration, it seems our limited resources would be most effectively committed elsewhere...
Cheers,
Sean |
On Tue, Jun 28, 2016 at 6:36 AM, Sean P. DeNigris <[hidden email]> wrote:
> stepharo wrote >>> maybe we need to consider deprecate the amber client >>> and use a full-pharo version. >> >> Torsten what is the state of your solution? > > Is it worth it to take another trip down this road of rolling-our-own source > code repo? Whatever we create, we accept the responsibility to maintain, and > with GitHub's social coding features, BitBucket for free private repo > hosting, and all the advances in Pharo-git integration, it seems our limited > resources would be most effectively committed elsewhere... Jumping ahead to the end game of not needing to support development of the repository backend ourselves, there are a couple of levels to this... 1. Create a "SmalltalkHub" organisation on github and move *all* repositories (maintaining privacy. Synchronize between the two servers for a couple of years so as to not abandon old Pharo versions or break existing Configurations, or build a thin forwarding service such that requests received at smalltalkhub interact with github - perhaps this is read only. Build a thin web SmalltalkHub home page with github pages at smalltalkhub.io. 2. While GitHub gets most of the glory, its closed source and there are some open source git options to consider like GitLab (MIT license) or Gerrit (Apache license). This might be the path to choose if we need some Smalltalk customizations like Smalltalk syntax highlighting. The advantage of integrating with GitLab would be that the community could use their hosted solution, but private companies could run their own GitLab server if they have secrets they want to be more careful about sharing with third parties. 3. We might run a GitLab/Gerrit server in place of the existing Smalltalkhub server, and make it look the same for pre-git Pharo clients. There would still be some administration cost, but a larger community for support, features and bug fixing, or paid support options. * https://www.linux.com/learn/how-run-your-own-git-server * https://about.gitlab.com/applications/ * https://www.gerritcodereview.com/ * https://gerrit-review.googlesource.com/Documentation/config-plugins.html But these considerations shouldn't stop an intermediate solution. cheers -ben |
With regards to GitLab and Metacello. A couple of years ago, I looked
into adding GitLab support to Metacello, similar to `github:\\` for downloading repository without requiring git to be installed and found that there were issues[1] ... Now that was in 2014 and it's possible that GitLab has fiddled with their zip download support, but I haven't checked ... `github://` is convenient but if you are moving to full git support and expect everyone to be cloning projects into local repos (by hook or by crook) not being able to download a zip version of the project is less of a problem ... Dale [1] https://github.com/dalehenrich/metacello-work/issues/287#issuecomment-59815235 On 6/27/16 7:05 PM, Ben Coman wrote: > On Tue, Jun 28, 2016 at 6:36 AM, Sean P. DeNigris <[hidden email]> wrote: >> stepharo wrote >>>> maybe we need to consider deprecate the amber client >>>> and use a full-pharo version. >>> Torsten what is the state of your solution? >> Is it worth it to take another trip down this road of rolling-our-own source >> code repo? Whatever we create, we accept the responsibility to maintain, and >> with GitHub's social coding features, BitBucket for free private repo >> hosting, and all the advances in Pharo-git integration, it seems our limited >> resources would be most effectively committed elsewhere... > Jumping ahead to the end game of not needing to support development of > the repository backend ourselves, > there are a couple of levels to this... > > 1. Create a "SmalltalkHub" organisation on github and move *all* > repositories (maintaining privacy. Synchronize between the two servers > for a couple of years so as to not abandon old Pharo versions or break > existing Configurations, or build a thin forwarding service such that > requests received at smalltalkhub interact with github - perhaps this > is read only. Build a thin web SmalltalkHub home page with github > pages at smalltalkhub.io. > > 2. While GitHub gets most of the glory, its closed source and there > are some open source git options to consider like GitLab (MIT license) > or Gerrit (Apache license). This might be the path to choose if we > need some Smalltalk customizations like Smalltalk syntax highlighting. > The advantage of integrating with GitLab would be that the community > could use their hosted solution, but private companies could run their > own GitLab server if they have secrets they want to be more careful > about sharing with third parties. > > 3. We might run a GitLab/Gerrit server in place of the existing > Smalltalkhub server, and make it look the same for pre-git Pharo > clients. There would still be some administration cost, but a larger > community for support, features and bug fixing, or paid support > options. > * https://www.linux.com/learn/how-run-your-own-git-server > * https://about.gitlab.com/applications/ > * https://www.gerritcodereview.com/ > * https://gerrit-review.googlesource.com/Documentation/config-plugins.html > > But these considerations shouldn't stop an intermediate solution. > cheers -ben > |
I just checked and it seems that GitLab has indeed changed the download
filenames to the point where I think that a `gitlab://` url for Metacello could be supported ... Dale On 6/28/16 8:43 AM, Dale Henrichs wrote: > With regards to GitLab and Metacello. A couple of years ago, I looked > into adding GitLab support to Metacello, similar to `github:\\` for > downloading repository without requiring git to be installed and found > that there were issues[1] ... Now that was in 2014 and it's possible > that GitLab has fiddled with their zip download support, but I haven't > checked ... > > `github://` is convenient but if you are moving to full git support > and expect everyone to be cloning projects into local repos (by hook > or by crook) not being able to download a zip version of the project > is less of a problem ... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/issues/287#issuecomment-59815235 > > > On 6/27/16 7:05 PM, Ben Coman wrote: >> On Tue, Jun 28, 2016 at 6:36 AM, Sean P. DeNigris >> <[hidden email]> wrote: >>> stepharo wrote >>>>> maybe we need to consider deprecate the amber client >>>>> and use a full-pharo version. >>>> Torsten what is the state of your solution? >>> Is it worth it to take another trip down this road of >>> rolling-our-own source >>> code repo? Whatever we create, we accept the responsibility to >>> maintain, and >>> with GitHub's social coding features, BitBucket for free private repo >>> hosting, and all the advances in Pharo-git integration, it seems our >>> limited >>> resources would be most effectively committed elsewhere... >> Jumping ahead to the end game of not needing to support development of >> the repository backend ourselves, >> there are a couple of levels to this... >> >> 1. Create a "SmalltalkHub" organisation on github and move *all* >> repositories (maintaining privacy. Synchronize between the two servers >> for a couple of years so as to not abandon old Pharo versions or break >> existing Configurations, or build a thin forwarding service such that >> requests received at smalltalkhub interact with github - perhaps this >> is read only. Build a thin web SmalltalkHub home page with github >> pages at smalltalkhub.io. >> >> 2. While GitHub gets most of the glory, its closed source and there >> are some open source git options to consider like GitLab (MIT license) >> or Gerrit (Apache license). This might be the path to choose if we >> need some Smalltalk customizations like Smalltalk syntax highlighting. >> The advantage of integrating with GitLab would be that the community >> could use their hosted solution, but private companies could run their >> own GitLab server if they have secrets they want to be more careful >> about sharing with third parties. >> >> 3. We might run a GitLab/Gerrit server in place of the existing >> Smalltalkhub server, and make it look the same for pre-git Pharo >> clients. There would still be some administration cost, but a larger >> community for support, features and bug fixing, or paid support >> options. >> * https://www.linux.com/learn/how-run-your-own-git-server >> * https://about.gitlab.com/applications/ >> * https://www.gerritcodereview.com/ >> * >> https://gerrit-review.googlesource.com/Documentation/config-plugins.html >> >> But these considerations shouldn't stop an intermediate solution. >> cheers -ben >> > |
Free forum by Nabble | Edit this page |