- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fast way to load package form github

by Sven Van Caekenberghe

On 26 Apr 2014, at 10:16, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Also if there is no better way, can anybody tell me how to add a configuration to pharo 3 meta repo? Can I get an access or I should send an .mcz to somebody? Metacello is the best solution indeed. If you are part of team 'Pharo' on StHub you can just copy the configuration. If you give me your username I can give you access.

April 26, 2014

Re: [Pharo-dev] Fast way to load package form github

by Yuriy Tymchuk

Also if there is no better way, can anybody tell me how to add a configuration to pharo 3 meta repo? Can I get an access or I should send an .mcz to somebody? Uko On 26 Apr 2014, at 09:34, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Yes, but this requires user to clone the repository, this is not as fast as just Gofer with Monticello. I know that there is a support for github:// URIs in Metacello, but as far as I remember they donât work in Gofer. > > Uko > > On 26 Apr 2014, at 09:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Gofer with a filetree:// URL as package ? >> >> Using the Monticello UI Tool you can just add a repo, select filetree as type and load any package. >> >> On 26 Apr 2014, at 09:21, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> Hi guys, sorry if there was already this question, but is there a fast way to load a package from github (saved with filetree)? Iâm looking for some way to tell people: execute âthisâ and you will have my package in your image. >>> >>> Cheers >>> Uko >> >> > >

April 26, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Sven Van Caekenberghe

On 26 Apr 2014, at 09:37, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > I've quite often opened a REPL on Rails apps in the production environment. You can basically execute everything on the production environment. This is quite useful for checking what's going on (usually a mismatch between your development/staging environment and the production one). That is what I mean, exactly. > Beware that you do not connect to the serving process that your customer is seeing. You just spin a new REPL process with the production settings. And frankly it was usually more than enough to find what you need to fix. > > > > > On Fri, Apr 25, 2014 at 11:18 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > On Apr 25, 2014, at 5:48 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> look into a running server' to find or investigate a problem makes all the difference > > yeah, I agree. Logs are the last resource and hot debugs are unbeatable. They can cut costs a lot when investigating in the real environment where the problem happens and Smalltalkâs debugger is the closest thing to a developer-with-problem dream-tool that the industry can give. > >

April 26, 2014

Re: [Pharo-dev] Debugging in Production Servers

by FranÃ§ois Stephany

I've quite often opened a REPL on Rails apps in the production environment. You can basically execute everything on the production environment. This is quite useful for checking what's going on (usually a mismatch between your development/staging environment and the production one). Beware that you do not connect to the serving process that your customer is seeing. You just spin a new REPL process with the production settings. And frankly it was usually more than enough to find what you need to fix. On Fri, Apr 25, 2014 at 11:18 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > > On Apr 25, 2014, at 5:48 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > look into a running server' to find or investigate a problem makes all the > difference > > > yeah, I agree. Logs are the last resource and hot debugs are unbeatable. > They can cut costs *a lot* when investigating in the real environment > where the problem happens and Smalltalkâs debugger is the closest thing to > a developer-with-problem dream-tool that the industry can give. > >

April 26, 2014

Re: [Pharo-dev] Fast way to load package form github

by Yuriy Tymchuk

Yes, but this requires user to clone the repository, this is not as fast as just Gofer with Monticello. I know that there is a support for github:// URIs in Metacello, but as far as I remember they donât work in Gofer. Uko On 26 Apr 2014, at 09:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Gofer with a filetree:// URL as package ? > > Using the Monticello UI Tool you can just add a repo, select filetree as type and load any package. > > On 26 Apr 2014, at 09:21, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Hi guys, sorry if there was already this question, but is there a fast way to load a package from github (saved with filetree)? Iâm looking for some way to tell people: execute âthisâ and you will have my package in your image. >> >> Cheers >> Uko > >

April 26, 2014

Re: [Pharo-dev] Fast way to load package form github

by Sven Van Caekenberghe

Gofer with a filetree:// URL as package ? Using the Monticello UI Tool you can just add a repo, select filetree as type and load any package. On 26 Apr 2014, at 09:21, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, sorry if there was already this question, but is there a fast way to load a package from github (saved with filetree)? Iâm looking for some way to tell people: execute âthisâ and you will have my package in your image. > > Cheers > Uko

April 26, 2014

Fast way to load package form github

by Yuriy Tymchuk

Hi guys, sorry if there was already this question, but is there a fast way to load a package from github (saved with filetree)? Iâm looking for some way to tell people: execute âthisâ and you will have my package in your image. Cheers Uko

April 26, 2014

Help needed to compile a fresh Mac Carbon VM

by David T. Lewis

VM hackers and Mac enthusiasts, we need your help. Here is your chance to earn big karma points, along with the grateful admiration of the your peers. What we need: A freshly compiled Mac Carbon VM, just like the Squeak 4.2.5beta1U VM on http://squeakvm.org/mac, but updated to use current VM sources, and to include CameraPlugin and ScratchPlugin. Why we need it: See below. We have a GSOC project mentor who needs to do work on a Mac, who needs to run an image format 6502 (pre-closure) image, and is running into problems related to the outdated Mac VM. We need an update to the Mac VM so that the GSOC project can proceed, and to prevent problems like this for other Mac users who need to be able to run older images (Etoys, Scratch, etc). http://www.google-melange.com/gsoc/project/details/google/gsoc2014/positive… If you have the ability to compile a Mac Carbon VM and make it available to the community, then please speak up. We need your help. (Cross posted to several lists, but discussion should go to vm-dev if possible) Thanks in advance, Dave On Thu, Apr 24, 2014 at 07:55:33PM -0400, Steve Thomas wrote: > David, > > I really appreciate the help and prompt reply. > > I checked and it does work under a previous version of OSX (10.7.2) > > Cheers, > Stephen > > > On Thu, Apr 24, 2014 at 5:01 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > Hi Steve, > > > > I am not a Mac user but I do work with the Squeak VM so I would like to > > help if I can. > > > > Just for my understanding - the camera works on older versions of OSX, but > > not on your OSX 10.9.2, is that correct? > > > > The camera plugin, which is required for using the camera in Etoys, was > > added to the Mac VM after the VM was originally built. The plugin was > > compiled somewhat differently from the other plugins in the VM, which may > > account for it working on one version of OS X and not on another. > > > > If that is the case, then we may need to find a volunteer to rebuild the > > VM with all necessary plugins included. I am not a Mac expert at all, but > > I think that is the likely source of the difficulty. > > > > Unfortunately we have been short handed on Mac support for the VM, but if > > you can confirm that this is the kind of problem that you are seeing, I > > can put out a call for help on the vm-dev list and see if we can find a > > volunteer do the necessary update. > > > > Thanks, > > > > Dave > > > > > I downloaded latest software using "update code from server" and still no > > > luck. > > > > > > > > > > > > > > > Need this for Google Summer of Code project I will be mentoring > > > > > http://www.google-melange.com/gsoc/project/details/google/gsoc2014/positive… > > > < > > http://www.google-melange.com/gsoc/project/details/google/gsoc2014/positive… > > > > > > > > > Cheers, > > > Stephen > > > _______________________________________________ > > > etoys-dev mailing list > > > etoys-dev(a)squeakland.org > > > http://lists.squeakland.org/mailman/listinfo/etoys-dev > > > > >

April 26, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Sebastian Sastre

On Apr 25, 2014, at 5:48 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > look into a running server' to find or investigate a problem makes all the difference yeah, I agree. Logs are the last resource and hot debugs are unbeatable. They can cut costs a lot when investigating in the real environment where the problem happens and Smalltalkâs debugger is the closest thing to a developer-with-problem dream-tool that the industry can give.

April 25, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Esteban A. Maringolo

2014-04-25 17:48 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 25 Apr 2014, at 22:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> To me... an interactive debugger in the production environment is not a requirement. > > Hmm, but that _is_ a key point: often being able to 'look into a running server' to find or investigate a problem makes all the difference - this interactivity can be much more productive than trying fixes blind. I value a nice stack dump or a FUEL dump (I haven't tried this), to recreate the context. I understand the fact that "a similar error context" is not the same as "the actual error context", but the truth is if the error is related with I/O (files, network, db...) it is not going to be simple to fix, and maybe the dependent party (a client on the other side) is already gone. That's why I said that, for me (emphasis here), it isn't a requirement, particularly to fix bugs. For live inspection and modifications I DO FIND it valuable. Esteban A. Maringolo

April 25, 2014