Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes
Sean P. DeNigris wrote: Sean P. DeNigris wrote Where did you click on it? I need steps to reproduce... Okay, I tried to merge it and got the error when the package was being read... I did some experiments... * create a zip at Mac command line - new Pharo code correctly parses date/times * unzip Balloon-CamilloBruni.85.mcz at Mac command line - Mac reports date/time as 1/23/2010... I'm assuming this is wrong because pre-fix, Pharo reported 29 September 2011 So, I think the code is correct, but transitioning is a problem... let me see write up a fallback defaulting to the old date format for invalid dates... -- View this message in context: http://forum.world.st/zip-bug-IMPORTANT-probably-related-to-the-recent-Zip-changes-tp4634224p4634247.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. What do you get if you unzip it outside Pharo? from the operating system?
Re: [Pharo-project] recompiling class
On Jun 9, 2012, at 8:16 PM, Eliot Miranda wrote: For the backend of Opal, I did some crude benchmark for Martin this week: Decompiling to IR and re-generating of all methods in Morph that access iVars takes 0.8 seconds... and how long does recompiling all Morph methods take? on the same machine: 6.5 seconds. But of course that can be cut down by selecting for ivar access (to around half). More statistics: Bytecode to IR for the whole image: 4.5 seconds. BC-IR-BC: 12.7 seconds. (no install) Opal image (~57000 CompiledMethods) Not installing the methods yet... and of course nothing is profiled and optimized yet. Marcus, I'm eager to port your code to Squeak. Would that be OK? Yes! The first version will be (I think) portable. But future versions might use Pharo features. Compatibility is not the main goal. The whole point about improving the system is to then use the improvements. Else what's the point in improving anything? Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] recompiling class
On Jun 11, 2012, at 7:17 AM, S Krish wrote: decompile to an Intermediate Representation This will be nice to have backported if possible to 1.4. IR: you can do it. Whole compiler: no way, as it changes APIs and honestly, life is too short. Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] recompiling class
+1. It is in your interest to get us to move to the latest version, and the best way to do it is to keep offering irresistible reasons :) Cheers, Doru On Mon, Jun 11, 2012 at 9:31 AM, Marcus Denker marcus.den...@inria.fr wrote: On Jun 11, 2012, at 7:17 AM, S Krish wrote: decompile to an Intermediate Representation This will be nice to have backported if possible to 1.4. IR: you can do it. Whole compiler: no way, as it changes APIs and honestly, life is too short. Marcus -- Marcus Denker -- http://marcusdenker.de -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-project] [Vm-dev] Re: Plan/discussion/communication around new object format
Some extra ideas. 1. Avoiding extra header for big sized objects. I not sure about this, but still .. according to Eliot's design: 8: slot size (255 = extra header word with large size) What if we extend size to 16 bits (so in total it will be 65536 slots) and we have a single flag, pointing how to calculate object size: flag(0) object size = (size field) * 8 flag(1) object size = 2^ (slot field) which means that past 2^16 (or how many bits we dedicate to size field in header) all object sizes will be power of two. Since most of the objects will fit under 2^16, we don't lose much. For big arrays, we could have a special collection/array, which will store exact size in it's inst var (and we even don't need to care in cases of Sets/Dicts/OrderedCollections). Also we can actually make it transparent: Array classnew: size size (max exact size ) ifTrue: [ ^ ArrayWithBigSizeWhatever new: size ] of course, care must be taken for those variable classes which potentially can hold large amounts of bytes (like Bitmap). But i think code can be quickly adopted to this feature of VM, which will simply fail a #new: primitive if size is not power of two for sizes greater than max exact size which can fit into size field of header. 2. Slot for arbitrary properties. If you read carefully, Eliot said that for making lazy become it is necessary to always have some extra space per object, even if object don't have any fields: We shall probably keep the minimum object size at 16 bytes so that there is always room for a forwarding pointer. So, this fits quite well with idea of having slot for dynamic properties per object. What if instead of extending object when it requires extra properties slot, we just reserve the slot for properties at the very beginning: [ header ] [ properties slot] ... rest of data .. so, any object will have that slot. And in case of lazy-become. we can use that slot for holding forwarding pointer. Voila. 3. From 2. we going straight back to hash.. VM don't needs to know such a thing as object's hash, it has no semantic load inside VM, it just answers those bits by a single primitive. So, why it is kind of enforced inherent property of all objects in system? And why nobody asks, if we have that one, why we could not have more than one or as many as we want? This is my central question around idea of having per-object properties. Once VM will guarantee that any object can have at least one slot for storing object reference (property slot), then it is no longer needed for VM to care about identity hash. Because it can be implemented completely at language size. But most of all, we are NO longer limited how big/small hash values , which directly converts into bonuses: less hash collisions more performance. Want 64-bit hash? 128-bit? Whatever you desire: ObjectidentityHash ^ self propertiesAt: #hash ifAbsentPut: [ HashGenerator newHashValue ] and once we could have per-object properties.. and lazy become, things like Magma will get a HUGE benefits straightly out of the box. Because look, lazy become, immutability - those two addressing many problems related to OODB implementation (i barely see other use cases, where immutability would be as useful as in cases of OODB).. so for me it is logical to have this last step: by adding arbitrary properties, OODB now can store the ID there. -- Best regards, Igor Stasenko.
Re: [Pharo-project] recompiling class
On 11 June 2012 09:26, Marcus Denker marcus.den...@inria.fr wrote: The whole point about improving the system is to then use the improvements. Else what's the point in improving anything? Hi, from Capt. Obvious :) Marcus -- Marcus Denker -- http://marcusdenker.de -- Best regards, Igor Stasenko.
[Pharo-project] FileReference #exists not working?
imagine 'foo.txt' file exists in my image directory, if I do: 'foo.txt' asFileReference exits - true. 'foo.txt' asFileReference delete (the file is removed from the OS) 'foo.txt' asFileReference exits - true. shouldn't be false now? couldn't debug it yet... sorry -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] FileReference #exists not working?
can be related to http://code.google.com/p/pharo/issues/detail?id=5693 so... you should download latest vm to try it. On Jun 11, 2012, at 11:24 AM, Mariano Martinez Peck wrote: imagine 'foo.txt' file exists in my image directory, if I do: 'foo.txt' asFileReference exits - true. 'foo.txt' asFileReference delete (the file is removed from the OS) 'foo.txt' asFileReference exits - true. shouldn't be false now? couldn't debug it yet... sorry -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] Look and font competition
As this gif shows, and I prefer, the SBDIC buttons should be hidden away and prefereably as a drop down as it used to be earlier. In normal dev workflow, its rare to slip to using this access and even if its often, I find it to my aesthetic sense a little better to have an usual drop down list.
Re: [Pharo-project] Squeaksource is...
good reminder that i should migrate my stuff to sthub On 11 June 2012 11:05, Bernat Romagosa tibabenfortlapala...@gmail.com wrote: ...down :) Can someone take a look, please? -- Bernat Romagosa. -- Best regards, Igor Stasenko.
Re: [Pharo-project] Squeaksource is...
Hi, the problem seems to be the server on which squeaksource is, not squeaksource itself. I will restart the server ASAP. Cheers, Fabrizio 2012/6/11 Bernat Romagosa tibabenfortlapala...@gmail.com ...down :) Can someone take a look, please? -- Bernat Romagosa.
Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes
Ben Coman wrote What do you get if you unzip it outside Pharo? from the operating system? Sean P. DeNigris wrote * unzip Balloon-CamilloBruni.85.mcz at Mac command line - Mac reports date/time as 1/23/2010... I'm assuming this is wrong because pre-fix, Pharo reported 29 September 2011 So Mac's zip came up with a valid, but bogus date; while Pharo raised an error... -- View this message in context: http://forum.world.st/zip-bug-IMPORTANT-probably-related-to-the-recent-Zip-changes-tp4634224p4634299.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] FileReference #exists not working?
EstebanLM wrote can be related to http://code.google.com/p/pharo/issues/detail?id=5693 That one was effecting symlinks. It's more probably related to... http://forum.world.st/FilePlugin-changed-it-s-behavior-td4633565.html There's something weird and scary going on with FilePlugin... * Issue 6050: ensureDirectory looks strange http://code.google.com/p/pharo/issues/detail?id=6050 * http://forum.world.st/FilePlugin-bug-td4634074.html -- View this message in context: http://forum.world.st/FileReference-exists-not-working-tp4634285p4634300.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] Pharo-1.4-Tests » 32,mac - Build # 68 - Failure!
BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/Pharo-1.4-Tests/./Architecture=32,OS=mac/68/Project:Architecture=32,OS=macDate of build:Mon, 11 Jun 2012 16:19:29 +0200Build duration:1 min 21 secCHANGESNo ChangesCONSOLE OUTPUT[...truncated 921 lines...] do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles BlockClosure>>ensure: BasicCodeLoader>>installSourceFiles BasicCodeLoader class>>commandLineHandlerAction: [:commandLine | BasicCodeLoader commandLineHandlerAction: commandLine] in BasicCodeLoader class>>initialize [:each | | actionBlock conditionBlock | conditionBlock := each key. actionBlock := each value. (conditionBlock value: anUserInput) ifTrue: [actionBlock value: anUserInput]] in CommandLine class(AbstractUserInput class)>>dispatch: [:association | aBlock value: association value] in Dictionary>>valuesDo: [:each | each ifNotNil: [aBlock value: each]] in Dictionary>>associationsDo: Array(SequenceableCollection)>>do: Dictionary>>associationsDo: Dictionary>>valuesDo: Dictionary>>do: CommandLine class(AbstractUserInput class)>>dispatch: [self dispatch: singleton] in CommandLine class>>dispatch BlockClosure>>cull: [each cull: resuming] in [:each | self logStartUpErrorDuring: [each cull: resuming] into: errors tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions: BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: [:each | self logStartUpErrorDuring: [each cull: resuming] into: errors tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions: OrderedCollection>>do: SmalltalkImage>>executeDeferredStartupActions: SmalltalkImage>>snapshot:andQuit: UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [| chunk | val := (self peekFor: $!) ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. self class evaluatorClass evaluate: chunk logged: true]] in [:bar | [self atEnd] whileFalse: [bar value: self position. self skipSeparators. [| chunk | val := (self peekFor: $!) ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. self class evaluatorClass evaluate: chunk logged: true]] on: InMidstOfFileinNotification do: [:ex | ex resume: true]. self skipStyleChunk]. self close] in FileSystemFileStream(PositionableStream)>>fileInAnnouncing: BlockClosure>>on:do: [:bar | [self atEnd] whileFalse: [bar value: self position. self skipSeparators. [| chunk | val := (self peekFor: $!) ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. self class evaluatorClass evaluate: chunk logged: true]] on: InMidstOfFileinNotification do: [:ex | ex resume: true]. self skipStyleChunk]. self close] in FileSystemFileStream(PositionableStream)>>fileInAnnouncing: NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: -- and more not shown -THERE_BE_DRAGONS_HERE Got startup errors: ---THERE_BE_DRAGONS_HERE GoferRepositoryError: Could not access http://www.squeaksource.com/CISupport: ConnectionTimedOut: Cannot connect to 130.92.65.106:80 --- Build step 'Execute shell' marked build as failureRecording test resultsJDK installation skipped: Unknown CPU name: mac os xJDK installation skipped: Unknown CPU name: mac os xDescription set: Email was triggered for: FailureSending email for trigger: Failure
[Pharo-project] Pharo Core 1.3 - Build # 41 - Failure!
BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/Pharo%20Core%201.3/41/Project:Pharo Core 1.3Date of build:Mon, 11 Jun 2012 16:19:24 +0200Build duration:1 min 48 secCHANGESNo ChangesBUILD ARTIFACTSPharoCore-1.3.changesPharoCore-1.3.imagePharoCore-1.3.zipCONSOLE OUTPUT[...truncated 1075 lines...] MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: --Process: a Process in Delay class>>handleTimerEventstack:Delay class>>handleTimerEvent Delay class>>runTimerEventLoop [self runTimerEventLoop] in Delay class>>startTimerEventLoop [self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in [self value. Processor terminateActive] in BlockClosure>>newProcessstack:[self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in [self value. Processor terminateActive] in BlockClosure>>newProcessstack:[self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in [self value. Processor terminateActive] in BlockClosure>>newProcessstack:[self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in [self value. Processor terminateActive] in BlockClosure>>newProcessstack:[self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in [delaySemaphore wait] in Delay>>waitstack:[delaySemaphore wait] in Delay>>wait BlockClosure>>ifCurtailed: Delay>>wait InputEventPollingFetcher>>waitForInput InputEventPollingFetcher(InputEventFetcher)>>eventLoop [self eventLoop] in InputEventPollingFetcher(InputEventFetcher)>>installEventLoop [self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in SmalltalkImage>>lowSpaceWatcherstack:SmalltalkImage>>lowSpaceWatcher [self lowSpaceWatcher] in SmalltalkImage>>installLowSpaceWatcher [self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in ProcessorScheduler class>>idleProcessstack:ProcessorScheduler class>>idleProcess [self idleProcess] in ProcessorScheduler class>>startUp [self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in WeakArray class>>finalizationProcessstack:WeakArray class>>finalizationProcess [self finalizationProcess] in WeakArray class>>restartFinalizationProcess [self value. Processor terminateActive] in BlockClosure>>newProcess --Process: a Process in Process>>terminatestack:Process>>terminate -- Build step 'Execute shell' marked build as failureArchiving artifactsRecording test resultsDescription set: Email was triggered for: FailureSending email for trigger: Failure
[Pharo-project] Pharo-1.4-Tests » 32,linux - Build # 68 - Failure!
BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/Pharo-1.4-Tests/./Architecture=32,OS=linux/68/Project:Architecture=32,OS=linuxDate of build:Mon, 11 Jun 2012 16:19:29 +0200Build duration:1 min 23 secCHANGESNo ChangesCONSOLE OUTPUT[...truncated 919 lines...] Array(SequenceableCollection)>>do: [sourceFiles do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles BlockClosure>>ensure: BasicCodeLoader>>installSourceFiles BasicCodeLoader class>>commandLineHandlerAction: [:commandLine | BasicCodeLoader commandLineHandlerAction: commandLine] in BasicCodeLoader class>>initialize [:each | | actionBlock conditionBlock | conditionBlock := each key. actionBlock := each value. (conditionBlock value: anUserInput) ifTrue: [actionBlock value: anUserInput]] in CommandLine class(AbstractUserInput class)>>dispatch: [:association | aBlock value: association value] in Dictionary>>valuesDo: [:each | each ifNotNil: [aBlock value: each]] in Dictionary>>associationsDo: Array(SequenceableCollection)>>do: Dictionary>>associationsDo: Dictionary>>valuesDo: Dictionary>>do: CommandLine class(AbstractUserInput class)>>dispatch: [self dispatch: singleton] in CommandLine class>>dispatch BlockClosure>>cull: [each cull: resuming] in [:each | self logStartUpErrorDuring: [each cull: resuming] into: errors tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions: BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: [:each | self logStartUpErrorDuring: [each cull: resuming] into: errors tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions: OrderedCollection>>do: SmalltalkImage>>executeDeferredStartupActions: SmalltalkImage>>snapshot:andQuit: UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [| chunk | val := (self peekFor: $!) ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. self class evaluatorClass evaluate: chunk logged: true]] in [:bar | [self atEnd] whileFalse: [bar value: self position. self skipSeparators. [| chunk | val := (self peekFor: $!) ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. self class evaluatorClass evaluate: chunk logged: true]] on: InMidstOfFileinNotification do: [:ex | ex resume: true]. self skipStyleChunk]. self close] in FileSystemFileStream(PositionableStream)>>fileInAnnouncing: BlockClosure>>on:do: [:bar | [self atEnd] whileFalse: [bar value: self position. self skipSeparators. [| chunk | val := (self peekFor: $!) ifTrue: [(self class evaluatorClass evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. self class evaluatorClass evaluate: chunk logged: true]] on: InMidstOfFileinNotification do: [:ex | ex resume: true]. self skipStyleChunk]. self close] in FileSystemFileStream(PositionableStream)>>fileInAnnouncing: NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: -- and more not shown -THERE_BE_DRAGONS_HERE Got startup errors: ---THERE_BE_DRAGONS_HERE GoferRepositoryError: Could not access http://www.squeaksource.com/CISupport: ConnectionTimedOut: Cannot connect to 130.92.65.106:80 --- Build step 'Execute shell' marked build as failureRecording test resultsDescription set: Email was triggered for: FailureSending email for trigger: Failure
Re: [Pharo-project] Squeaksource is...
Bernat Romagosa wrote ...down :) Don't forget about the mirror (for loading anyway)... http://www.dsal.cl/squeaksource/ Instructions on how to redirect MC... http://lists.gforge.inria.fr/pipermail/pharo-users/2011-August/002749.html -- View this message in context: http://forum.world.st/Squeaksource-is-tp4634284p4634305.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] Pharo 2.0 Jenkins build failing
It looks like it's related to the progress bar overhaul... I have a pretty good idea what's going on... I'm working on it now... Sean -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Squeaksource is...
Hi, Squeakcource is up again. Cheers, Fabrizio 2012/6/11 Sean P. DeNigris s...@clipperadams.com Bernat Romagosa wrote ...down :) Don't forget about the mirror (for loading anyway)... http://www.dsal.cl/squeaksource/ Instructions on how to redirect MC... http://lists.gforge.inria.fr/pipermail/pharo-users/2011-August/002749.html -- View this message in context: http://forum.world.st/Squeaksource-is-tp4634284p4634305.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] FileReference #exists not working?
both were same problem and both *should* (not completely sure, he) work on latest vm, please check :) (if we can get jenkings to work again, :) On Jun 11, 2012, at 4:20 PM, Sean P. DeNigris wrote: EstebanLM wrote can be related to http://code.google.com/p/pharo/issues/detail?id=5693 That one was effecting symlinks. It's more probably related to... http://forum.world.st/FilePlugin-changed-it-s-behavior-td4633565.html There's something weird and scary going on with FilePlugin... * Issue 6050: ensureDirectory looks strange http://code.google.com/p/pharo/issues/detail?id=6050 * http://forum.world.st/FilePlugin-bug-td4634074.html -- View this message in context: http://forum.world.st/FileReference-exists-not-working-tp4634285p4634300.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Pharo 2.0 Jenkins build failing
I think I have a fix... The bug was the new progress bar wasn't integrated with headless mode... just testing now and I'll upload... - S -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634321.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] [update 2.0] #20127
20127 - - Issue 5967: Use FileSystem for everything (part three). **THANKS** camillo for this effort Files-CamilloBruni.ducasse.251 System-FileRegistry-CamilloBruni.16 System-Support-CamilloBruni.634 Kernel-CamilloBruni.1103 Stef and Camillo
[Pharo-project] [update 2.0] #20128
20128 - - Issue 5967: Use FileSystem for everything (part Four). **THANKS** camillo for this effort Making sure we can save the image :) Yes previous version was in a strange state… Stef and Camillo
Re: [Pharo-project] Pharo 2.0 Jenkins build failing
Fix attached to: Issue 6055: [BUG] New System Progress doesn't work when headless http://code.google.com/p/pharo/issues/detail?id=6055 2.0 When headless and displaying progress, with used to be a no-op, now there is a BlockClosure DNU label:. This is because progress used to use a block that was pretending to be a class, so #value: would get sent everywhere, with the selector as the argument (e.g. value: #label). Now that we have a real progress object, we are sending #label: explicitly. Since CommandLineUIManager wasn't updated, it's still passing a block ([:bar |]), which obviously doesn't understand #label: The attached st files fix CommandLineUIManager to use a DummySystemProgressItem instead of a block. There will be more refactoring of the entire system progress framework, but let's get it working, one step at a time. N.B. The DummySystemProgressItem was temporarily placed in its own category to avoid making Morphic-Widgets dirty, which would be wiped out as the updates to 20119 are loaded -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634339.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] [update 2.0] #20129
20129 - - Issue 5967: Use FileSystem for everything (part Five). **THANKS** camillo for this effort Collections-Abstract-CamilloBruni.165 Collections-Native-CamilloBruni.7 Collections-Arrayed-CamilloBruni.68 MenuRegistration-CamilloBruni.39 Polymorph-Widgets-CamilloBruni.641 System-CommandLine-CamilloBruni.23 System-Change Notification-MarcusDenker.25 Tools-CamilloBruni.859 Refactoring-Spelling-CamilloBruni.30 System-Platforms-CamilloBruni.20 System-Text-CamilloBruni.211 StartupPreferences-CamilloBruni.47 System-Installers-MarcusDenker.18 Spec-Tools-CamilloBruni.27 System-Object Storage-CamilloBruni.160 System-FilePackage-CamilloBruni.67 Zinc-HTTP-CamilloBruni.257 Zinc-Tests-CamilloBruni.132 KernelTests-CamilloBruni.411 Ring-Core-Kernel-CamilloBruni.58 Ring-Tests-Kernel-CamilloBruni.26 Traits-CamilloBruni.418 Ring-Monticello-CamilloBruni.3
[Pharo-project] Undeclared in Spec
Hi, we have got two new Undeclared and thus failing testUndeclared. Both Undeclared are related to Spec - references to instance variable widget and references to global SpecLayout. -- Pavel
[Pharo-project] FileStream not opening file, if file opened elsewhere
Hello, I have run into what seems to be a bug in FileStream/StandardFileStream. I attempt to open a file. f := StandardFileStream oldFileNamed: 'pathToFile'. If file is open elsewhere for editing, f = nil. If the file is not open elsewhere, then the file opens properly. If I attempt to open read only. f := StandardFileStream readOnlyFileNamed: 'pathToFile'. Opens the file properly. It seems to me that returning nil is an ugly response. I had no knowledge why the file was not opening. At the time did not know I had it open in another application. Failing silently is not nice. I would have preferred an Error message or something telling me that the file was open elsewhere and even possibly letting me open as readOnly. When we attempt to open a file with a filename that does not exist, we get the nice option of either selecting (or correcting) a file name which exists or creating a new file with the specified name. With a small amount of naive browsing, I was not able to find where the understanding of the file being locked elsewhere is found. So I only offer my experience. Thanks. Jimmie
Re: [Pharo-project] FileReference #exists not working?
On Mon, Jun 11, 2012 at 5:21 PM, Esteban Lorenzano esteba...@gmail.comwrote: both were same problem and both *should* (not completely sure, he) work on latest vm, please check :) please, tell me EXACTLY which job. https://ci.lille.inria.fr/pharo/view/VM-dev/ has 6 jobs. https://ci.lille.inria.fr/pharo/view/Cog/ has 11 jobs https://ci.lille.inria.fr/pharo/view/VM/ has 1 job. so...which one? (if we can get jenkings to work again, :) On Jun 11, 2012, at 4:20 PM, Sean P. DeNigris wrote: EstebanLM wrote can be related to http://code.google.com/p/pharo/issues/detail?id=5693 That one was effecting symlinks. It's more probably related to... http://forum.world.st/FilePlugin-changed-it-s-behavior-td4633565.html There's something weird and scary going on with FilePlugin... * Issue 6050: ensureDirectory looks strange http://code.google.com/p/pharo/issues/detail?id=6050 * http://forum.world.st/FilePlugin-bug-td4634074.html -- View this message in context: http://forum.world.st/FileReference-exists-not-working-tp4634285p4634300.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Mariano http://marianopeck.wordpress.com
[Pharo-project] FileReference should throw error when deleting unexisting files?
So if we now do: 'afileThatDoesntExist' asFileReference delete I get a PrimitiveFailed. If this is what we want, can I add: FileReference deleteIfExists self exists ifTrue: [ self delete] or something like that? because lots of places (tearDown of tests) I want to remove crao which may or may not exist... thanks -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] FileReference #exists not working?
Sean P. DeNigris wrote * Issue 6050: ensureDirectory looks strange http://code.google.com/p/pharo/issues/detail?id=6050 The code snippet works now with the Jenkins Cog VM at https://ci.lille.inria.fr/pharo/job/Cog-VM/ (build #45 - last successful) Good... that was a scary one. How was it resolved? -- View this message in context: http://forum.world.st/FileReference-exists-not-working-tp4634285p4634359.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] FilePlugin changed it's behavior?
Sean P. DeNigris wrote There's something weird and scary going on with FilePlugin... * Issue 6050: ensureDirectory looks strange http://code.google.com/p/pharo/issues/detail?id=6050 * http://forum.world.st/FilePlugin-bug-td4634074.html Fixed... see http://forum.world.st/FileReference-gt-gt-exists-not-working-td4634285.html -- View this message in context: http://forum.world.st/FilePlugin-changed-it-s-behavior-tp4633565p4634362.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] FileReference #exists not working?
none :) (they should be not active, and removed soon) use this: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/ Esteban On Jun 11, 2012, at 8:33 PM, Mariano Martinez Peck wrote: On Mon, Jun 11, 2012 at 5:21 PM, Esteban Lorenzano esteba...@gmail.com wrote: both were same problem and both *should* (not completely sure, he) work on latest vm, please check :) please, tell me EXACTLY which job. https://ci.lille.inria.fr/pharo/view/VM-dev/ has 6 jobs. https://ci.lille.inria.fr/pharo/view/Cog/ has 11 jobs https://ci.lille.inria.fr/pharo/view/VM/ has 1 job. so...which one? (if we can get jenkings to work again, :) On Jun 11, 2012, at 4:20 PM, Sean P. DeNigris wrote: EstebanLM wrote can be related to http://code.google.com/p/pharo/issues/detail?id=5693 That one was effecting symlinks. It's more probably related to... http://forum.world.st/FilePlugin-changed-it-s-behavior-td4633565.html There's something weird and scary going on with FilePlugin... * Issue 6050: ensureDirectory looks strange http://code.google.com/p/pharo/issues/detail?id=6050 * http://forum.world.st/FilePlugin-bug-td4634074.html -- View this message in context: http://forum.world.st/FileReference-exists-not-working-tp4634285p4634300.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] FileReference #exists not working?
digging with Camillo in the code implementation and realizing that there was a bug in the plugin support files :) Esteban On Jun 11, 2012, at 8:49 PM, Sean P. DeNigris wrote: Sean P. DeNigris wrote * Issue 6050: ensureDirectory looks strange http://code.google.com/p/pharo/issues/detail?id=6050 The code snippet works now with the Jenkins Cog VM at https://ci.lille.inria.fr/pharo/job/Cog-VM/ (build #45 - last successful) Good... that was a scary one. How was it resolved? -- View this message in context: http://forum.world.st/FileReference-exists-not-working-tp4634285p4634359.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
On Mon, Jun 11, 2012 at 8:38 PM, Mariano Martinez Peck marianop...@gmail.com wrote: So if we now do: 'afileThatDoesntExist' asFileReference delete I get a PrimitiveFailed. If this is what we want, can I add: FileReference deleteIfExists self exists ifTrue: [ self delete] So I discussed in IRC and Camillo and Sean recommended to use #ensureDelete because it is concistent to ensureFile and ensureDirecotry etc... for me #ensureDelete sounds the opposite to what this method does because I am not ensuring anything, if fact, I won't remove anything if the file does not exist. Camilo also suggested to do FileReference deleteIfExists self deleteIfAbsent: [ ] FileReference deleteIfAbsent: aBlock self exists ifTrue: [self delete] ifFalse: [aBock value] What do you think? which one do you like more? #ensureDelete or #deleteIfExists? do you also agree to add the intermediate #deleteIfAbsent: ? Cheers or something like that? because lots of places (tearDown of tests) I want to remove crao which may or may not exist... thanks -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com
[Pharo-project] 2.0
I grabbed the one-click image and poked around. The worst thing I found (can't reproduce) is that the SB's package list became insensitive to clicks. Switching to groups and then back seemed to restore normal operation. Looks good so far! Bill
Re: [Pharo-project] Pharo 2.0 Jenkins build failing
Thanks Sean. I'm going to paris for a presentation so I may have a look tomorrow evening. Stef On Jun 11, 2012, at 6:33 PM, Sean P. DeNigris wrote: Fix attached to: Issue 6055: [BUG] New System Progress doesn't work when headless http://code.google.com/p/pharo/issues/detail?id=6055 2.0 When headless and displaying progress, with used to be a no-op, now there is a BlockClosure DNU label:. This is because progress used to use a block that was pretending to be a class, so #value: would get sent everywhere, with the selector as the argument (e.g. value: #label). Now that we have a real progress object, we are sending #label: explicitly. Since CommandLineUIManager wasn't updated, it's still passing a block ([:bar |]), which obviously doesn't understand #label: The attached st files fix CommandLineUIManager to use a DummySystemProgressItem instead of a block. There will be more refactoring of the entire system progress framework, but let's get it working, one step at a time. N.B. The DummySystemProgressItem was temporarily placed in its own category to avoid making Morphic-Widgets dirty, which would be wiped out as the updates to 20119 are loaded -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634339.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] recompiling class
+ 1 and we are working on that :) Soon we will be able to remove FileDirectory :), will have Morph rendered in Athens…. On Jun 11, 2012, at 9:45 AM, Tudor Girba wrote: +1. It is in your interest to get us to move to the latest version, and the best way to do it is to keep offering irresistible reasons :) Cheers, Doru On Mon, Jun 11, 2012 at 9:31 AM, Marcus Denker marcus.den...@inria.fr wrote: On Jun 11, 2012, at 7:17 AM, S Krish wrote: decompile to an Intermediate Representation This will be nice to have backported if possible to 1.4. IR: you can do it. Whole compiler: no way, as it changes APIs and honestly, life is too short. Marcus -- Marcus Denker -- http://marcusdenker.de -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes
On Jun 11, 2012, at 3:47 AM, Sean P. DeNigris wrote: so I'm refactoring blind!! Scary :) Yes I know that feeling….
Re: [Pharo-project] recompiling class
Stéphane Ducasse wrote Soon we will be able to remove FileDirectory :) Yippie! -- View this message in context: http://forum.world.st/recompiling-class-tp4633989p4634388.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
Mariano Martinez Peck marianop...@gmail.com writes: On Mon, Jun 11, 2012 at 8:38 PM, Mariano Martinez Peck marianop...@gmail.com wrote: So if we now do: 'afileThatDoesntExist' asFileReference delete I get a PrimitiveFailed. If this is what we want, can I add: FileReference deleteIfExists self exists ifTrue: [ self delete] So I discussed in IRC and Camillo and Sean recommended to use #ensureDelete because it is concistent to ensureFile and ensureDirecotry etc... for me #ensureDelete sounds the opposite to what this method does because I am not ensuring anything, if fact, I won't remove anything if the file does not exist. I like #ensureDelete, because yes, it is consistent. I see it as make sure the file is deleted, so it makes sense to me. Maybe #ensureDeleted would be better? Nico Camilo also suggested to do FileReference deleteIfExists self deleteIfAbsent: [ ] FileReference deleteIfAbsent: aBlock self exists ifTrue: [self delete] ifFalse: [aBock value] What do you think? which one do you like more? #ensureDelete or #deleteIfExists? do you also agree to add the intermediate #deleteIfAbsent: ? Cheers or something like that? because lots of places (tearDown of tests) I want to remove crao which may or may not exist... thanks -- Mariano http://marianopeck.wordpress.com -- Nicolas Petton http://nicolas-petton.fr
Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
On Mon, Jun 11, 2012 at 2:32 PM, petton.nico...@gmail.com wrote: Maybe #ensureDeleted would be better? Nico I like #ensureDeleted (make sure it doesn't exist)
Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes
On Mon, Jun 11, 2012 at 2:58 AM, Sean P. DeNigris s...@clipperadams.comwrote: ... If that's the case, maybe wrap the unzip with a check that defaults to the old format if the date is invalid or strange (e.g. year 1962)... What's strange about 1962? I happen to think it's a rather nice year ;-) -- Cheers, Peter
Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
Chris Cunningham wrote I like #ensureDeleted (make sure it doesn't exist) Makes sense... +1 -- View this message in context: http://forum.world.st/FileReference-should-throw-error-when-deleting-unexisting-files-tp4634357p4634396.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] DBXTalk seaside / success in Pier one-click / my 1.4 woes follow-up
Yanni, I did not know that my post to http://groups.google.com/group/dbxtalk would end up on the pharo lists. Also, this was a side-note to other points about DBXTalk... or I would have given more information about this one aspect. But I am thrilled that Fuel works for you, so I would love to learn more about what works. My Pier download was what was available on Saturday at http://www.piercms.com/download. Then as I noted in that post, I pulled in DBXTalk according to specs on http://dbxtalk.smallworks.com.ar/Download/. I ran through some many variations on image builds in recent days it is a blur. I believe I used the default Magritte in the Pier image -- Magritte2 is the only one I see in the repository (with magritte in the name). *What version Magritte should I be using?* As an aside, in a 1.4 build, I pulled in Magritte3 via the following, and that fixed some name conflicts. Is this the proper way to load it to work with seaside? Gofer new renggli: 'magritte3'; package: 'Magritte-Model'; package: 'Magritte-Pharo-Model'; package: 'Magritte-Seaside'; package: 'Magritte-Pharo-Seaside'; package: 'Magritte-Morph'; package: 'Magritte-Tests-Model'; package: 'Magritte-Tests-Pharo-Model'; load. Then Fuel was loaded using the specs on http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/Installation . I did the Basic Demo: - Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load. And the Basic Demo from the above mentioned page was tried and failed. Actually... wait, the debugger ... -- actually, I do not have time to replicate it right now. But the above scripts, running Pier on a Mac failed. I forget why. I've never had a problem with Fuel in a Pier image. What problem are you having? (It helps if you are specific in your post; otherwise, people have to ask.) That is Great News! You imply that it always works, so I will try again. It works fine in a Pharo1.4 image I am working with. What Pier one-click image did you use (link please)? Was it Magritte2 or Magritte3? How did you load Fuel? Did you use ConfigurationOf? Did you specify #stable or #bleedingEdge Thanks for any insight you can offer in advance. Cheers, Cam
Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
I generally default to saying of course there should be an error. I much prefer to get my bad news early rather than having to fish around or it after the fact. Toward that end, I would recommend having #deleteIfAbsent: and #delete that provides an error-raising block and forwards to #deleteifAbsent:. That is consistent with collections, which are not a bad model/source-of-inspiration for managing directory contents. Having #ensureDeleted in addition to above does no real harm. I would prefer that the selector start with delete so it appears close to the other methods in browsers, even w/o category filtering - makes it more discoverable. Just my 2 asCents. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham...@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files? On Mon, Jun 11, 2012 at 2:32 PM, petton.nico...@gmail.com wrote: Maybe #ensureDeleted would be better? Nico I like #ensureDeleted (make sure it doesn't exist)
Re: [Pharo-project] Pharo 2.0 Jenkins build failing
Stéphane Ducasse wrote Thanks Sean. I'm going to paris for a presentation so I may have a look tomorrow evening. No problem. If anybody needs the latest update (#20129 currently) before then, the st files attached to the issue are only needed to update heedlessly. Otherwise, you can download 20119 from Jenkins and do a software update via the world menu (or programmatically). n.b. the latest Cog Jit VM on Jenkins crashes when doing this update. The latest Jenkins Stack VM works fine. HTH, Sean -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634400.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] DBXTalk seaside / success in Pier one-click / my 1.4 woes follow-up
On 11/06/12 7:39 PM, Cameron Sanders wrote: My Pier download was what was available on Saturday at http://www.piercms.com/download. I thought you were referring to a build from: http://jenkins.lukas-renggli.ch/view/Seaside%203.0/ On that site is a Pier3/Margritte3/Seaside-3.1 build as well. However, AFAICT, all the builds are based on Pharo-1.3, which may be an issue for you. I build my image from Pharo-1.4, adding Seaside-3.0, Magritte2, Pier2. Then as I noted in that post, I pulled in DBXTalk according to specs on http://dbxtalk.smallworks.com.ar/Download/. I've used an earlier Glorp port, without problem, but don't use Glorp anymore. I've never used the latest DBXTalk. The Phoseydon scaffolding seems interesting, but you might want to ask the authors what their opinion is on its readiness (the last I remember, from a year or two ago, is was a first release). Note that Magritte3 was done earlier this year, so you may have some issues there. *What version Magritte should I be using?* The one that works for you :). Seriously though, Pier seems to be okay with either Magritte version, so whichever one Phoseydon needs will settle it - IIUC, Phoseydon uses Magritte, but I'm too lazy to check at the moment. As an aside, in a 1.4 build, I pulled in Magritte3 via the following, and that fixed some name conflicts. What name conflicts did you have? What tools had the conflicts? One of the key fixes of Magritte3 was to eliminate overloading of the #description method. Is this the proper way to load it to work with seaside? That's the way I would load it (but I'd leave off the Morphic stuff). ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load. I use version 1.7, but because I don't want the other packages in the image, I only load: FuelTests-MartinDias.157.mcz Fuel-MartinDias.479.mcz I've not tried the 1.8 version yet. If you're having trouble with Fuel, you might want to load and run the tests. Thanks for any insight you can offer in advance. Whenever I add a new framework, I start from my base image which has all the frameworks that I currently use. Then I load and run the tests for the new framework I want to use. If there are problems, I then start from a basic Pharo image (plus any pre-req packages for the new framework). You should not have to do this, unless you are using frameworks that are relatively new, or you're using a newer Pharo image.
Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch
Do we all agree that standardizing on the Unix Epoch is the way to go? The argument on the squeak list seemed to be: - the squeak epoch has a certain beauty to it, being the turn of the century vs - why reinvent the wheel? Everybody already knows what the unix epoch is (e.g. you can point them to Wikipedia) The full discussion is here: http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581.html#a4630814 The main thing is to make sure that whatever we use is based on UTC and not local time. So - two options - PharoOffset := 1 January, 1901 UTC - Unix offset Also, whatever we change it to (and IMHO it really needs to be changed), I think existing live objects from previous Pharos (e.g. that are materialized with fuel) may be invalid (like the recent zip/mcz consequences) -- View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4634403.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] DBXTalk seaside / success in Pier one-click / my 1.4 woes follow-up
Yanni, Thanks! http://jenkins.lukas-renggli.**ch/view/Seaside%203.0/http://jenkins.lukas-renggli.ch/view/Seaside%203.0/ On that site is a Pier3/Margritte3/Seaside-3.1 build as well. Oh, maybe I will try that as a starting point. Thanks! However, AFAICT, all the builds are based on Pharo-1.3, which may be an issue for you. I want to use Seaside, Magritte, Fuel (as a back-up storage facility, though primary right now), and Glorp via DBXTalk for relational DB I/O. That's my goal. Perhaps you are right and I am too early at adopting DBXTalk. It looks like it should simplify some of the DB storage. I build my image from Pharo-1.4, adding Seaside-3.0, Magritte2, Pier2. I do not need Pier per se. Rather, I simply had no images where the basic Magritte tutorials worked. None of them worked properly right out of the box. But you are saying that Magritte2 in Pharo-1.4, with Seaside 3.0 works together... ... ... so I will try it again. Do you need 1.4, and why? -- if you do not mind sharing. - Let me say: because these configuration problems can be such a pain, especially when one is not aware of the nuances of various packages one might want to adopt, I only recently abandoned my Pharo-1.2 one-click derived image when I had troubles connecting to a DB. I figured it was time to do a complete upgrade. But it has turned into a nightmare, and my project has hit a standstill, ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load. I use version 1.7, but because I don't want the other packages in the image, I only load: FuelTests-MartinDias.157.mcz Fuel-MartinDias.479.mcz Thank you! I've not tried the 1.8 version yet. If you're having trouble with Fuel, you might want to load and run the tests. In 1.4 Fuel worked out of the box, but in the Pier based image, it did not. Thanks for any insight you can offer in advance. Whenever I add a new framework, I start from my base image which has all the frameworks that I currently use. Then I load and run the tests for the new framework I want to use. If there are problems Pending your answers to my query about why you chose 1.4 over 1.3, I will start fresh again. Cheers Thanks, Cam
Re: [Pharo-project] Pharo 2.0 Jenkins build failing
Sean P. DeNigris wrote the latest Cog Jit VM on Jenkins crashes when doing this update. The latest Jenkins Stack VM works fine. Disregard that. OS X was picking up an old vm on my system. The latest Jit and Stack VMs both work. -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634406.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] DBXTalk seaside / success in Pier one-click / my 1.4 woes follow-up
On 11/06/12 10:35 PM, Cameron Sanders wrote: Do you need 1.4, and why? -- if you do not mind sharing. I was building on 1.3, and had a second automated build which tracked 1.4. Periodically, I would manually update the 1.4 base image of the build to the then latest 1.4. Each of the builds would load the framework packages I needed, then load my code base. This way I could see problems with the frameworks or my code, as 1.4 progressed. At some point 1.4 was stable enough that I switched over (about 6 months ago). ... I only recently abandoned my Pharo-1.2 one-click derived image when I had troubles connecting to a DB. I figured it was time to do a complete upgrade. But it has turned into a nightmare, and my project has hit a standstill, Yep, you don't want to be caught by surprise, when upgrading. Pending your answers to my query about why you chose 1.4 over 1.3, I will start fresh again. In your situation, I would choose 1.4, because Seaside, Magritte2/3, DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached to Omnibrowser, then there is no reason to use 1.3.
[Pharo-project] [PLP] News
PaulLePoulpe Logger is now working and tested on Pharo 1.3 core; 1.4 and 2.0, and working with two red tests at Pharo 1.2 core. The two red tests are related with an announcement issue. But it dont interfere with the work, so, it works. I'm using it actively in ConcreteTypeInference and KwisatzHaderach projects swiching configurations depending on which project im working, and work perfect. That's why i decided to make the first version. Gofer new url: 'http://ss3.gemstone.com/ss/PaulLePoulpe'; package: 'ConfigurationOfPaulLePoulpe'; load. ( (Smalltalk at: #ConfigurationOfPaulLePoulpe) project version:'1.0' ) load
Re: [Pharo-project] DBXTalk seaside / success in Pier one-click / my 1.4 woes follow-up
Great, Thanks for the feedback! Good points. I appreciate it. Ciao, Cam On Mon, Jun 11, 2012 at 11:27 PM, Yanni Chiu ya...@rogers.com wrote: On 11/06/12 10:35 PM, Cameron Sanders wrote: Do you need 1.4, and why? -- if you do not mind sharing. I was building on 1.3, and had a second automated build which tracked 1.4. Periodically, I would manually update the 1.4 base image of the build to the then latest 1.4. Each of the builds would load the framework packages I needed, then load my code base. This way I could see problems with the frameworks or my code, as 1.4 progressed. At some point 1.4 was stable enough that I switched over (about 6 months ago). ... I only recently abandoned my Pharo-1.2 one-click derived image when I had troubles connecting to a DB. I figured it was time to do a complete upgrade. But it has turned into a nightmare, and my project has hit a standstill, Yep, you don't want to be caught by surprise, when upgrading. Pending your answers to my query about why you chose 1.4 over 1.3, I will start fresh again. In your situation, I would choose 1.4, because Seaside, Magritte2/3, DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached to Omnibrowser, then there is no reason to use 1.3.
Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch
On Mon, Jun 11, 2012 at 7:15 PM, Sean P. DeNigris s...@clipperadams.comwrote: Do we all agree that standardizing on the Unix Epoch is the way to go? No :) The argument on the squeak list seemed to be: - the squeak epoch has a certain beauty to it, being the turn of the century vs - why reinvent the wheel? Everybody already knows what the unix epoch is (e.g. you can point them to Wikipedia) The full discussion is here: http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581.html#a4630814 The main thing is to make sure that whatever we use is based on UTC and not local time. So - two options - PharoOffset := 1 January, 1901 UTC - Unix offset Also, whatever we change it to (and IMHO it really needs to be changed), I think existing live objects from previous Pharos (e.g. that are materialized with fuel) may be invalid (like the recent zip/mcz consequences) -- View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4634403.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- best, Eliot
Re: [Pharo-project] [PLP] News
Here is a related release-post :) http://concretetypeinference.blogspot.com.ar/2012/06/metacello-paullepoulpe-project-version.html 2012/6/12 Santiago Bragagnolo santiagobragagn...@gmail.com PaulLePoulpe Logger is now working and tested on Pharo 1.3 core; 1.4 and 2.0, and working with two red tests at Pharo 1.2 core. The two red tests are related with an announcement issue. But it dont interfere with the work, so, it works. I'm using it actively in ConcreteTypeInference and KwisatzHaderach projects swiching configurations depending on which project im working, and work perfect. That's why i decided to make the first version. Gofer new url: 'http://ss3.gemstone.com/ss/PaulLePoulpe'; package: 'ConfigurationOfPaulLePoulpe'; load. ( (Smalltalk at: #ConfigurationOfPaulLePoulpe) project version:'1.0' ) load
Re: [Pharo-project] recompiling class
Soon we will be able to remove FileDirectory :) Yippie! even more than that :)
Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
Yes to me ensureDelete or ensureDeleted is not explicit enough. I prefer remove/delete[ifAbsent:] On Jun 12, 2012, at 1:41 AM, Schwab,Wilhelm K wrote: I generally default to saying of course there should be an error. I much prefer to get my bad news early rather than having to fish around or it after the fact. Toward that end, I would recommend having #deleteIfAbsent: and #delete that provides an error-raising block and forwards to #deleteifAbsent:. That is consistent with collections, which are not a bad model/source-of-inspiration for managing directory contents. Having #ensureDeleted in addition to above does no real harm. I would prefer that the selector start with delete so it appears close to the other methods in browsers, even w/o category filtering - makes it more discoverable. Just my 2 asCents. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham...@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files? On Mon, Jun 11, 2012 at 2:32 PM, petton.nico...@gmail.com wrote: Maybe #ensureDeleted would be better? Nico I like #ensureDeleted (make sure it doesn't exist)
