April 2014 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Debugging in Production Servers

by Sven Van Caekenberghe

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.

April 25, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Esteban A. Maringolo

What I found useful is the ability to patch (compile code) in a running server. That's really a plus when you can't shutdown the server. To me... an interactive debugger in the production environment is not a requirement. Esteban A. Maringolo 2014-04-25 17:38 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: > > > On Apr 25, 2014, at 7:01 AM, askoh <askoh(a)askoh.com> wrote: > > Thanks for all the comments. Let me distilled what I have learned. Correct > me > if I am wrong. > > In Smalltalk: > Production environment and development environment are very similar if not > identical. > Runtime and debug modes are identical. So, debugging is instantaneous > available. > Debugging occurs at the context of the exception itself - not in a handler > or somewhere else. > Debugger, nah, the whole environment allows doit's, code changes and resumes > always. > Reflection is constantly available for debugging and logging. > > Can we coin a term for these capabilities/properties? Can we define a > standard to gauge programming environments? > > > great question, yeah I can validate that for airflowing. > > Those features allowed us to do hot maintenance more than once > > At least a couple of times we did it live with a real customer on the other > side, it was really great but donât get too excited, managing a real bug and > a real customer's perception both at the same time requires a lot of muscle > > sebastian > > o/ > >

April 25, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Sebastian Sastre

On Apr 25, 2014, at 7:01 AM, askoh <askoh(a)askoh.com> wrote: > Thanks for all the comments. Let me distilled what I have learned. Correct me > if I am wrong. > > In Smalltalk: > Production environment and development environment are very similar if not > identical. > Runtime and debug modes are identical. So, debugging is instantaneous > available. > Debugging occurs at the context of the exception itself - not in a handler > or somewhere else. > Debugger, nah, the whole environment allows doit's, code changes and resumes > always. > Reflection is constantly available for debugging and logging. > > Can we coin a term for these capabilities/properties? Can we define a > standard to gauge programming environments? great question, yeah I can validate that for airflowing. Those features allowed us to do hot maintenance more than once At least a couple of times we did it live with a real customer on the other side, it was really great but donât get too excited, managing a real bug and a real customer's perception both at the same time requires a lot of muscle sebastian o/

April 25, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Chris Muller

On Fri, Apr 25, 2014 at 5:01 AM, askoh <askoh(a)askoh.com> wrote: > Thanks for all the comments. Let me distilled what I have learned. Correct me > if I am wrong. > > In Smalltalk: > Production environment and development environment are very similar if not > identical. The "environments" on my laptop are the same as my production server? No, one should never count on that. > Runtime and debug modes are identical. So, debugging is instantaneous > available. What about everyone's obsession with shrinking? No one minds a "luxurious" IDE image for development, but most of us seem hell-bent on deploying "minimal" production servers totally stripped of those IDE/debugging luxuries. Now, I'm sure the debugger itself is not stripped, so that's better than nothing, unless running true headless with no way to get a window on the image. We're certainly "able" to do it, but it seems like our desire to shrink might cause need for some balance that provides the best of both worlds..

April 25, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30836 Home: https://github.com/pharo-project/pharo-core

April 25, 2014