- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core] cc556a: 30836

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: cc556a900432d496cec5c85bcf11682f37e6bb80 https://github.com/pharo-project/pharo-core/commit/cc556a900432d496cec5c85b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-25 (Fri, 25 Apr 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script489.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30836.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Polymorph.package/PolymorphSystemSettings.class/class/desktop/pharoLogoContents.st Log Message: ----------- 30836 11931 Use new flat Pharo logo https://pharo.fogbugz.com/f/cases/11931 http://files.pharo.org/image/30/30836.zip

April 25, 2014

Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM

by Nicolas Cellier

2014-04-25 17:38 GMT+02:00 GOUBIER Thierry <thierry.goubier(a)cea.fr>: > Hi Nicolas, > > from what you describe (double merge: one in git, one in MC), I wonder if > my decision to maintain compatibility between gitfiletree and FileTree by > writing the metadata (version / methodProperties) in gitfiletree is a good > thing? > > Thierry > > Very good question indeed. This is spoiling the efficiency of git for merging... I think that the answer is yes though, because not every one is using git (think Eliot's branch). Esteban is not publishing the MC packages back on SmalltalkHub for nothing. Those MC package would not be usable if they loosed their history, and I'm not sure that we are ready to loose that... Yet, resolving the (real code) merge conflicts in an external tool does not feel so cool to me, I'd like to specify git mergetool --pharo ;) Another way would be to not attempt a merge at all via git, it would be simpler to just pick the mc package somewhere, but I don't like it, we're loosing git traceability (and those nice github networks). Otherwise, if development was exclusively git driven, then we would be more comfortable with git tools. But still, we have the image which is a working copy, and not necessarily in sync with gitfiletree, so we have a more complex process than file based environments anyway : one more indirection. image <-> files <-> staged files <-> repo There is still one super-cool feature where git shines that we can use: jumping from one branch to another (modulo the image sync with files), the most usefull one IMO when we are mixing external platform files and Smalltalk code that require some sync. Nicolas ------------------------------ > *De :* Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de > Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] > *EnvoyÃ© :* vendredi 25 avril 2014 15:46 > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM > > > 2014-04-25 11:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Hi Nicolas, >> >> I cannot approve your pull requests because there are conflicts (I >> suspects is all the same conflict). >> >> can you fix them? >> >> thanks, >> Esteban >> > > Hi Esteban, > I don't think there is a single source code conflict... > But of course, there is allways 1 conflict : the MC meta information > mc/VMMaker-oscog.package/monticello.meta/version > > Since the branch was not forked from latest master, every other feature > branch will rot as soon as you integrate the first one. > That's the major limitation of gitfiletree. > > The way I found to workaround this is to : > > git checkout master > start an image in interactive mode, make sure to have current version > from gitfiletree loaded > > git fetch someRepo someBranch > git checkout someBranch > From the image, open git file tree and copy modifiedPackage in local MC > package-cache > > git checkout master > git merge someBranch > git mergetool > answer remote/local as you like for .meta/version and say [y] it's fixed > (you'll overwrite it soon after) > > From the image MC merge modifiedPackage copy from the package-cache > Republish the merged package in gitfiletree > git commit -a -m "Merge pull request #... (fix someBranch)" > > That's a bit heavier than a pure MC workflow, but it's bearable IMO... > > Tell me if this sounds clear enough. > > Another possibility is to do the exact mirror of this operation : merge > master branch in each someBranch. > But I don't think it's viable : > 1) If I have 10 branches, and don't know in which order you want to > integrate, then I'll have to do it 10+9+8+... times - that's 45 times this > operation > 2) If I know the order, I'll do that job in a single someBranch, it is > exactly the mirror of above operation : merge master into someBranch rather > than someBranch into master. But then it's both fragile (it can rot at any > time if you decide to interleave another fix), and it is against the spirit > of git : the feature branch should carry the minimum of changes IMO. > > The only advantage of this approach is to reduce the bottleneck effect > by reducing the work performed by the integrator, especially if you are > alone to cope with this burden... Unfortunately I'm out of time right now. > > I wanted to blog about it, but blogging is taking time... Hope my > explanations help. > > Cheers > >

April 25, 2014

Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM

by GOUBIER Thierry

Hi Nicolas, from what you describe (double merge: one in git, one in MC), I wonder if my decision to maintain compatibility between gitfiletree and FileTree by writing the metadata (version / methodProperties) in gitfiletree is a good thing? Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] EnvoyÃ© : vendredi 25 avril 2014 15:46 Ã : Pharo Development List Objet : Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM 2014-04-25 11:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>>: Hi Nicolas, I cannot approve your pull requests because there are conflicts (I suspects is all the same conflict). can you fix them? thanks, Esteban Hi Esteban, I don't think there is a single source code conflict... But of course, there is allways 1 conflict : the MC meta information mc/VMMaker-oscog.package/monticello.meta/version Since the branch was not forked from latest master, every other feature branch will rot as soon as you integrate the first one. That's the major limitation of gitfiletree. The way I found to workaround this is to : git checkout master start an image in interactive mode, make sure to have current version from gitfiletree loaded git fetch someRepo someBranch git checkout someBranch >From the image, open git file tree and copy modifiedPackage in local MC package-cache git checkout master git merge someBranch git mergetool answer remote/local as you like for .meta/version and say [y] it's fixed (you'll overwrite it soon after) >From the image MC merge modifiedPackage copy from the package-cache Republish the merged package in gitfiletree git commit -a -m "Merge pull request #... (fix someBranch)" That's a bit heavier than a pure MC workflow, but it's bearable IMO... Tell me if this sounds clear enough. Another possibility is to do the exact mirror of this operation : merge master branch in each someBranch. But I don't think it's viable : 1) If I have 10 branches, and don't know in which order you want to integrate, then I'll have to do it 10+9+8+... times - that's 45 times this operation 2) If I know the order, I'll do that job in a single someBranch, it is exactly the mirror of above operation : merge master into someBranch rather than someBranch into master. But then it's both fragile (it can rot at any time if you decide to interleave another fix), and it is against the spirit of git : the feature branch should carry the minimum of changes IMO. The only advantage of this approach is to reduce the bottleneck effect by reducing the work performed by the integrator, especially if you are alone to cope with this burden... Unfortunately I'm out of time right now. I wanted to blog about it, but blogging is taking time... Hope my explanations help. Cheers

April 25, 2014

Re: [Pharo-dev] Debugging in Production Servers

by kilon alios

AFAIK the term is "live coding" meaning the ability to fully code an application while it runs. On Fri, Apr 25, 2014 at 1:01 PM, 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? > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: > http://forum.world.st/Debugging-in-Production-Servers-tp4756136p4756451.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 25, 2014

Re: [Pharo-dev] Error adding a Class instVar

by Esteban A. Maringolo

Camille, all the classes in my hiearchy are in the toRebuild collection. But these others are also included: AdabasLikePlatform class AsyncFileReadStream class CannotAutomaticallyDetermineJoin class CannotFindSession class DialogWindowModel class DolphinDatabaseAccessor class DuplicatePrimaryKeyException class ExternalOSProcess class GlorpDatabaseReadError class GlorpDatabaseWriteError class GlorpIllegalCommand class GlorpInvalidExpressionError class GlorpInvalidTypeError class GlorpLinkTableAnywhereDescriptorSystem class GlorpTransactionFailure class GlorpWriteFailure class JQueryClass class JQueryInstance class MAMemoryFileModel class MBAbstractInfoList class MBLabelInfo class MBSpecInfo class MCClassDefinition MCClassDefinition class MCClassTraitDefinition MCClassTraitDefinition class MCFileTreeFileSystemUtils class MCMethodDefinition MCMethodDefinition class MCMockDefinition MCMockDefinition class MCOrganizationDefinition MCOrganizationDefinition class MCScriptDefinition MCScriptDefinition class MacOSProcessAccessor class MacProcess class MySQLPlatform class OS2OSProcessAccessor class OS2Process class ObjectStudioDatabaseAccessor class OcelotPlatform class OraclePlatform class PGAbstractStringResponse class PGAsciiRow class PGAuthentication class PGBackendKeyData class PGCancelRequest class PGColumnDescription class PGCopyInResponse class PGCopyOutResponse class PGFunctionCall class PGFunctionResultResponse class PGNotificationResponse class PGPasswordPacket class PGQuery class PGReadyForQuery class PGRowDescription class PGStartupPacket class PGTerminate class PostgreSQLPlatform class ProfStef class RBSLDAPAuthenticationProvider class RBSPostgresAuthenticationProvider class RBSSuperUserSession class RBSVoyageAuthenticationProvider class RiscOSProcess class RiscOSProcessAccessor class SQLServerPlatform class SQLite3Platform class SpecDebugActionButton class SqueakDatabaseAccessor class TextInputFieldModel class UIThemeVistary class UIThemeWatery class UnixProcess class VADatabaseAccessor class VWDatabaseAccessor class ValidationError class WAAncestryAttributeEditor class WABufferedResponse class WACacheAttributeEditor class WAComboResponse class WAConfigAttributeEditor class WAFileAttributeEditor class WAFileLibrary class WAFileMetadataLibrary class WAFilterAttributeEditor class WAStreamedResponse class WindowsOSProcessAccessor class WindowsProcess class WorldModel class Regards! Esteban A. Maringolo 2014-04-25 4:42 GMT-03:00 Camille Teruel <camille.teruel(a)gmail.com>: > > On 25 avr. 2014, at 09:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 25 Apr 2014, at 04:33, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> I was adding a Class instance variable when I got this, admittedly, funny error. >>> >>> Any clues of why? >>> >>> The class has a Trait (which I plan to remove). Maybe that is causing this? >> >> This is this problem: >> >> https://pharo.fogbugz.com/f/cases/13028/Adding-ClassVariables-corrupts-clas… > > No I don't think so, 13028 is the subclass cache problem whereas Esteban's problem seems to be related to wrong slot scope problem. > Esteban, is it the latest image? > Can run this script in your image and tell us the content of toRebuild? > > all := Smalltalk allClasses flatCollect: [ :e | { e . e class } ]. > candidates := all reject: [ :e | e superclass isNil or: [e layout slotScope isKindOf: LayoutEmptyScope ] ]. > toRebuild := candidates reject: [ :e | e superclass layout slotScope == e layout slotScope parentScope ]. > > Does toRebuild contains your class or one class of its hierarchy? > >> >> > >

April 25, 2014