Re: [Pharo-dev] Error adding a Class instVar
On 25 Apr 2014, at 04:33, Esteban A. Maringolo 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-class-hierarchy
Re: [Pharo-dev] Error adding a Class instVar
On 25 avr. 2014, at 09:13, Marcus Denker wrote:
>
> On 25 Apr 2014, at 04:33, Esteban A. Maringolo 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-class-hierarchy
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?
>
>
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30835 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 5d24c1: 30835
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 5d24c1e6d88000d16c22074380c5e668fa1510b5 https://github.com/pharo-project/pharo-core/commit/5d24c1e6d88000d16c22074380c5e668fa1510b5 Author: Jenkins Build Server Date: 2014-04-25 (Fri, 25 Apr 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script488.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30835.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/ContainerModel.class/instance/protocol/buildAdapterWithSpec.st Log Message: --- 30835 13225 SpecInterpreter should not reset bindings https://pharo.fogbugz.com/f/cases/13225 http://files.pharo.org/image/30/30835.zip
Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM
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 On 25 Apr 2014, at 01:16, Nicolas Cellier wrote: > I think this fix is essential and should be applied before releasing Pharo VM: > > https://github.com/pharo-project/pharo-vm/pull/31 > > Those are optionals but would be nice to have: > > https://github.com/pharo-project/pharo-vm/pull/32 > https://github.com/pharo-project/pharo-vm/pull/33 > https://github.com/pharo-project/pharo-vm/pull/34 > https://github.com/pharo-project/pharo-vm/pull/42 > > Those can wait but are ready and not dangerous IMO: > > https://github.com/pharo-project/pharo-vm/pull/37 > https://github.com/pharo-project/pharo-vm/pull/39 > https://github.com/pharo-project/pharo-vm/pull/40 > > This one works perfectly for me but failed on the CI server I really wonder > why... > > https://github.com/pharo-project/pharo-vm/pull/41 > > This one would be nice to have too but does not fully work on my mac. > I really fail to understand why... > The exact same code in Cog branch works perfectly with same compiler > (slightly different options maybe?) > I'd be curious to know if all Kernel-Number tests pass when compiled by > someone else. > > https://github.com/pharo-project/pharo-vm/pull/35 > > And last, the compiler flags should be fixed on MacOSX for bug > https://pharo.fogbugz.com/f/cases/11130 > Or clang replaced by an older gcc... >
Re: [Pharo-dev] Debugging in Production Servers
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.
[Pharo-dev] Units package access
Hi all, I think I have found a bug in Units and would like to correct it. I am using Units, and although it has some quirks (100 kg * (10 m / 1 t) should be 1 m and not 1000 kilogram metres per tonne), it is working well for me. But one point is a problem for me: the “=“ is no longer symmetric. The following things should be unequal: 10 kg = 10 s 10 kg = 10 10 = 10 kg But the thing is, that 10 kg = 10 actually returns true. So if someone can give me access I will fix this bug (with a test case). Regards, Diego
Re: [Pharo-dev] CPU usage change on newer OS
Here is mine. And it used to be around 2. Norbert top - 12:33:02 up 16 days, 15:45, 1 user, load average: 5,03, 6,69, 7,02 Tasks: 30 total, 1 running, 29 sleeping, 0 stopped, 0 zombie %Cpu(s): 13,8 us, 0,6 sy, 0,5 ni, 82,9 id, 2,2 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 32834868 total, 31193000 used, 1641868 free, 1449816 buffers KiB Swap: 33553332 total, 672508 used, 32880824 free. 21207288 cached Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 16667 mobility 20 0 72856 47096 2188 S 1,0 0,1 65:07.04 pharo-vm 22820 inbox 20 0 70500 43904 1344 S 1,0 0,1 26:37.38 pharo-vm 26745 events20 0 70500 40692 1264 S 1,0 0,1 145:37.59 pharo-vm 32093 geo 20 0 136308 47268 1436 S 1,0 0,1 92:17.80 pharo-vm 10523 gcm 20 0 82528 53152 2284 S 0,7 0,2 94:52.39 pharo-vm 11531 sms 20 0 70628 42096 1380 S 0,7 0,1 91:49.13 pharo-vm 18739 stats 20 0 70496 41980 1384 S 0,7 0,1 45:30.60 pharo-vm Am 25.04.2014 um 07:30 schrieb Sven Van Caekenberghe : > > On 25 Apr 2014, at 01:19, Esteban A. Maringolo wrote: > >> What % of CPU is it using? >> >> My VM on idle state consumes about ~4-5% CPU. > > That is about what I am used to, here is a real view of an Amazon AWS EC2 > Small Instance running 4 Pharo VMs: > > top - 05:25:09 up 413 days, 15:27, 1 user, load average: 0.88, 0.66, 0.49 > Tasks: 73 total, 3 running, 70 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.6%us, 0.4%sy, 0.0%ni, 96.3%id, 0.2%wa, 0.0%hi, 0.0%si, 2.5%st > Mem: 1706660k total, 1654928k used,51732k free, 136692k buffers > Swap:0k total,0k used,0k free, 1006556k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 31639 ubuntu20 0 1030m 99m 1444 R 4.0 5.9 61:47.82 pharo > > 4314 ubuntu20 0 1030m 162m 1504 S 2.0 9.7 140:28.55 pharo > > 8014 ubuntu20 0 1030m 77m 1512 S 2.0 4.6 561:06.30 pharo > > 31647 ubuntu20 0 1030m 92m 1444 R 2.0 5.6 63:31.80 pharo > > 1 root 20 0 3540 1392 732 S 0.0 0.1 0:58.61 init > > Sven > >> Esteban A. Maringolo >> >> >> 2014-04-24 15:43 GMT-03:00 Norbert Hartl : >>> I have a strange effect on my machines. I have a dedicated server and a lot >>> of virtual instances using LXC. The last few days I migrated most projects >>> of our projects from pharo2.0 to pharo3.0. And on the same time the images >>> moved from an ubuntu 12.04. system to a ubuntu 14.04 system. Looking at the >>> top command it appears the images/vms need noticable less CPU or better the >>> tools report less. The monitored overall CPU usage also is much lesser than >>> before. >>> >>> This is not proved by any measurement. Has anyone an idea why this could >>> happen or appear differently? >>> >>> Norbert >>> >> >
Re: [Pharo-dev] CPU usage change on newer OS
I remember Igor made a comment not so long ago about fixing something in the idle process (the relinquishBlaBla primitive). Maybe it's related... On Fri, Apr 25, 2014 at 2:35 PM, Norbert Hartl wrote: > Here is mine. And it used to be around 2. > > Norbert > > > top - 12:33:02 up 16 days, 15:45, 1 user, load average: 5,03, 6,69, 7,02 > Tasks: 30 total, 1 running, 29 sleeping, 0 stopped, 0 zombie > %Cpu(s): 13,8 us, 0,6 sy, 0,5 ni, 82,9 id, 2,2 wa, 0,0 hi, 0,0 si, > 0,0 st > KiB Mem: 32834868 total, 31193000 used, 1641868 free, 1449816 buffers > KiB Swap: 33553332 total, 672508 used, 32880824 free. 21207288 cached Mem > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > 16667 mobility 20 0 72856 47096 2188 S 1,0 0,1 65:07.04 > pharo-vm > 22820 inbox 20 0 70500 43904 1344 S 1,0 0,1 26:37.38 > pharo-vm > 26745 events20 0 70500 40692 1264 S 1,0 0,1 145:37.59 > pharo-vm > 32093 geo 20 0 136308 47268 1436 S 1,0 0,1 92:17.80 > pharo-vm > 10523 gcm 20 0 82528 53152 2284 S 0,7 0,2 94:52.39 > pharo-vm > 11531 sms 20 0 70628 42096 1380 S 0,7 0,1 91:49.13 > pharo-vm > 18739 stats 20 0 70496 41980 1384 S 0,7 0,1 45:30.60 > pharo-vm > > Am 25.04.2014 um 07:30 schrieb Sven Van Caekenberghe : > > > On 25 Apr 2014, at 01:19, Esteban A. Maringolo > wrote: > > What % of CPU is it using? > > My VM on idle state consumes about ~4-5% CPU. > > > That is about what I am used to, here is a real view of an Amazon AWS EC2 > Small Instance running 4 Pharo VMs: > > top - 05:25:09 up 413 days, 15:27, 1 user, load average: 0.88, 0.66, 0.49 > Tasks: 73 total, 3 running, 70 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.6%us, 0.4%sy, 0.0%ni, 96.3%id, 0.2%wa, 0.0%hi, 0.0%si, > 2.5%st > Mem: 1706660k total, 1654928k used,51732k free, 136692k buffers > Swap:0k total,0k used,0k free, 1006556k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 31639 ubuntu20 0 1030m 99m 1444 R 4.0 5.9 61:47.82 pharo > > 4314 ubuntu20 0 1030m 162m 1504 S 2.0 9.7 140:28.55 pharo > > 8014 ubuntu20 0 1030m 77m 1512 S 2.0 4.6 561:06.30 pharo > > 31647 ubuntu20 0 1030m 92m 1444 R 2.0 5.6 63:31.80 pharo > > 1 root 20 0 3540 1392 732 S 0.0 0.1 0:58.61 init > > Sven > > Esteban A. Maringolo > > > 2014-04-24 15:43 GMT-03:00 Norbert Hartl : > > I have a strange effect on my machines. I have a dedicated server and a > lot of virtual instances using LXC. The last few days I migrated most > projects of our projects from pharo2.0 to pharo3.0. And on the same time > the images moved from an ubuntu 12.04. system to a ubuntu 14.04 system. > Looking at the top command it appears the images/vms need noticable less > CPU or better the tools report less. The monitored overall CPU usage also > is much lesser than before. > > This is not proved by any measurement. Has anyone an idea why this could > happen or appear differently? > > Norbert > > > > >
Re: [Pharo-dev] CPU usage change on newer OS
Ok, but it is the same vm. The one that comes from the pharo ppa. Norbert Am 25.04.2014 um 14:43 schrieb Guillermo Polito : > I remember Igor made a comment not so long ago about fixing something in the > idle process (the relinquishBlaBla primitive). Maybe it's related... > > > On Fri, Apr 25, 2014 at 2:35 PM, Norbert Hartl wrote: > Here is mine. And it used to be around 2. > > Norbert > > > top - 12:33:02 up 16 days, 15:45, 1 user, load average: 5,03, 6,69, 7,02 > Tasks: 30 total, 1 running, 29 sleeping, 0 stopped, 0 zombie > %Cpu(s): 13,8 us, 0,6 sy, 0,5 ni, 82,9 id, 2,2 wa, 0,0 hi, 0,0 si, 0,0 > st > KiB Mem: 32834868 total, 31193000 used, 1641868 free, 1449816 buffers > KiB Swap: 33553332 total, 672508 used, 32880824 free. 21207288 cached Mem > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > 16667 mobility 20 0 72856 47096 2188 S 1,0 0,1 65:07.04 pharo-vm > 22820 inbox 20 0 70500 43904 1344 S 1,0 0,1 26:37.38 pharo-vm > 26745 events20 0 70500 40692 1264 S 1,0 0,1 145:37.59 pharo-vm > 32093 geo 20 0 136308 47268 1436 S 1,0 0,1 92:17.80 pharo-vm > 10523 gcm 20 0 82528 53152 2284 S 0,7 0,2 94:52.39 pharo-vm > 11531 sms 20 0 70628 42096 1380 S 0,7 0,1 91:49.13 pharo-vm > 18739 stats 20 0 70496 41980 1384 S 0,7 0,1 45:30.60 pharo-vm > > Am 25.04.2014 um 07:30 schrieb Sven Van Caekenberghe : > >> >> On 25 Apr 2014, at 01:19, Esteban A. Maringolo wrote: >> >>> What % of CPU is it using? >>> >>> My VM on idle state consumes about ~4-5% CPU. >> >> That is about what I am used to, here is a real view of an Amazon AWS EC2 >> Small Instance running 4 Pharo VMs: >> >> top - 05:25:09 up 413 days, 15:27, 1 user, load average: 0.88, 0.66, 0.49 >> Tasks: 73 total, 3 running, 70 sleeping, 0 stopped, 0 zombie >> Cpu(s): 0.6%us, 0.4%sy, 0.0%ni, 96.3%id, 0.2%wa, 0.0%hi, 0.0%si, >> 2.5%st >> Mem: 1706660k total, 1654928k used,51732k free, 136692k buffers >> Swap:0k total,0k used,0k free, 1006556k cached >> >> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND >> >> 31639 ubuntu20 0 1030m 99m 1444 R 4.0 5.9 61:47.82 pharo >> >> 4314 ubuntu20 0 1030m 162m 1504 S 2.0 9.7 140:28.55 pharo >> >> 8014 ubuntu20 0 1030m 77m 1512 S 2.0 4.6 561:06.30 pharo >> >> 31647 ubuntu20 0 1030m 92m 1444 R 2.0 5.6 63:31.80 pharo >> >> 1 root 20 0 3540 1392 732 S 0.0 0.1 0:58.61 init >> >> Sven >> >>> Esteban A. Maringolo >>> >>> >>> 2014-04-24 15:43 GMT-03:00 Norbert Hartl : I have a strange effect on my machines. I have a dedicated server and a lot of virtual instances using LXC. The last few days I migrated most projects of our projects from pharo2.0 to pharo3.0. And on the same time the images moved from an ubuntu 12.04. system to a ubuntu 14.04 system. Looking at the top command it appears the images/vms need noticable less CPU or better the tools report less. The monitored overall CPU usage also is much lesser than before. This is not proved by any measurement. Has anyone an idea why this could happen or appear differently? Norbert >>> >> > >
Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM
2014-04-25 11:26 GMT+02:00 Esteban Lorenzano : > 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 > > On 25 Apr 2014, at 01:16, Nicolas Cellier < > nicolas.cellier.aka.n...@gmail.com> wrote: > > I think this fix is essential and should be applied before releasing Pharo > VM: > > https://github.com/pharo-project/pharo-vm/pull/31 > > Those are optionals but would be nice to have: > > https://github.com/pharo-project/pharo-vm/pull/32 > https://github.com/pharo-project/pharo-vm/pull/33 > https://github.com/pharo-project/pharo-vm/pull/34 > https://github.com/pharo-project/pharo-vm/pull/42 > > Those can wait but are ready and not dangerous IMO: > > https://github.com/pharo-project/pharo-vm/pull/37 > https://github.com/pharo-project/pharo-vm/pull/39 > https://github.com/pharo-project/pharo-vm/pull/40 > > This one works perfectly for me but failed on the CI server I really > wonder why... > > https://github.com/pharo-project/pharo-vm/pull/41 > > This one would be nice to have too but does not fully work on my mac. > I really fail to understand why... > The exact same code in Cog branch works perfectly with same compiler > (slightly different options maybe?) > I'd be curious to know if all Kernel-Number tests pass when compiled by > someone else. > > https://github.com/pharo-project/pharo-vm/pull/35 > > And last, the compiler flags should be fixed on MacOSX for bug > https://pharo.fogbugz.com/f/cases/11130 > Or clang replaced by an older gcc... > > >
Re: [Pharo-dev] Error adding a Class instVar
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 :
>
> On 25 avr. 2014, at 09:13, Marcus Denker wrote:
>
>>
>> On 25 Apr 2014, at 04:33, Esteban A. Maringolo 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-class-hierarchy
>
> 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?
>
>>
>>
>
>
Re: [Pharo-dev] Debugging in Production Servers
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 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. > >
Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM
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-boun...@lists.pharo.org] de la part de Nicolas Cellier [nicolas.cellier.aka.n...@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 mailto:esteba...@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
Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM
2014-04-25 17:38 GMT+02:00 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 > > 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-boun...@lists.pharo.org] de la part de > Nicolas Cellier [nicolas.cellier.aka.n...@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 : > >> 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 > >
[Pharo-dev] [pharo-project/pharo-core] cc556a: 30836
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: cc556a900432d496cec5c85bcf11682f37e6bb80 https://github.com/pharo-project/pharo-core/commit/cc556a900432d496cec5c85bcf11682f37e6bb80 Author: Jenkins Build Server 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
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30836 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] Debugging in Production Servers
On Fri, Apr 25, 2014 at 5:01 AM, askoh 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..
Re: [Pharo-dev] Debugging in Production Servers
On Apr 25, 2014, at 7:01 AM, askoh 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/
Re: [Pharo-dev] Debugging in Production Servers
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 : > > > On Apr 25, 2014, at 7:01 AM, askoh 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/ > >
Re: [Pharo-dev] Debugging in Production Servers
On 25 Apr 2014, at 22:40, Esteban A. Maringolo 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.
Re: [Pharo-dev] Debugging in Production Servers
2014-04-25 17:48 GMT-03:00 Sven Van Caekenberghe : > > On 25 Apr 2014, at 22:40, Esteban A. Maringolo 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
Re: [Pharo-dev] Debugging in Production Servers
On Apr 25, 2014, at 5:48 PM, Sven Van Caekenberghe 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.
