Re: [Pharo-dev] Tests around Pharo
Well thank you again for your advices. We'll do operations for slices around 11-12 o'clock. For tests that Hilaire proposed (Dr Geo), we met some pharo committers during events in our university, and they suggested us to work mainly around collections, so we decided to focus to Collections part during the development time we had. About the license agreements I didn't see it anywhere, I will print it and send it to Damien this evening. Once our code will be accepted, we'll close the loop by reviewing the image integrating it. -- View this message in context: http://forum.world.st/Tests-around-Pharo-tp4777295p4784629.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] BlockClosure source code
On 14 Oct 2014, at 22:01, Tudor Girba tu...@tudorgirba.com wrote: I love these little things. This is a great example of how value should not be confused with cost. Small can be quite big after all :) It should be noted that there is almost no code “wasted” on this… the parser that creates the objects behind replaces InstructionPrinter (as we can just printOn: the SymbolicBytecodes for the longPrintString). The GTInspector related code is 5 short methods, in the end, after building the tool the system was smaller. Marcus
Re: [Pharo-dev] creating custom browsers out of GTInspector extensions
On 14 Oct 2014, at 23:26, Tudor Girba tu...@tudorgirba.com wrote: Hi, Now, that more people are playing with the GTInspector, I would like to raise another point that might otherwise go unnoticed: The inspector extensions do not only work in the inspector, but can also be combined in other browsers as well. We could replace (most of) the FileBrowser by GLMPager new with: [ :pager | pager show: [ :composite :file | composite title: file basename. file gtInspectorItemsIn: composite. file gtInspectorContentsIn: composite ]; title: 'FileBrowser' ]; openOn: FileSystem disk workingDirectory Where it replaces FileList linesOfCode == 1075 (plus three more helper classes). Of course this does a little bit more, but most of that is at the wrong spot anyway. (editor for text files, API for file selection on the class side). Marcus
Re: [Pharo-dev] [squeak-dev] Re: [Pharo-users] Trouble opening large files
Do we create an issue for the Pharo-vm? Stef On 14/10/14 21:29, Nicolai Hess wrote: Ah, good to know. At least for squeak, bug 7522 can be closed :) Nicolai 2014-10-14 20:49 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com mailto:eliot.mira...@gmail.com: Hi Nicolai, On Tue, Oct 14, 2014 at 11:26 AM, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de wrote: There is a bug report on mantis for squeaks unix vm. I think this applies to pharo too, although I don't know if this bug is still valid on recent squeak vm. http://bugs.squeak.org/view.php?id=7522 yes, one must compile with -D_FILE_OFFSET_BITS=64. The Cog VMs are also built with -D_GNU_SOURCE. Here's a line from a Squeak file list on the current Cog VM: (2014.10.11 07:00:46 7,115,143,880) Formula1.2014.Round16.Russia.Qualifying.BBCOneHD.1080i.H264.English-wserhkzt.ts No 32-bit limit here. 2014-10-14 17:43 GMT+02:00 Evan Donahue emdon...@gmail.com mailto:emdon...@gmail.com: The OS is Arch Linux. I can read the file with less. The problem, insofar as I can trace it, seems to stem from this line in UnixStore: Primitives lookupDirectory: encodedPath filename: encodedBasename When I have my 57G file there this line returns nil. If I move the 57G file and create a small file with the same name, the same command successfully finds the file. I am not sure how large a file must be to cause this issue, but A 1.5G file works fine. On Tue, Oct 14, 2014 at 8:17 AM, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2014-10-14 6:38 GMT+02:00 Evan Donahue emdon...@gmail.com mailto:emdon...@gmail.com: Hi, thanks for the reply. The response is the same: MessageNotUnderstood: FalsehumanReadableSIByteSize. This happens both to print-it as well as to do-it-and-go. Running the command on the neighboring wiki.torrent torrent file yields the correct 54kb. Thanks, Evan On Tue, Oct 14, 2014 at 12:24 AM, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: Hi, If I understand correctly, the failure occurs while navigating in the Items presentation. I cannot reproduce this problem because I do not have enough disk space for such a large file :). But, could you do the following and let me know what the outcome is: 'path/to/your/large/file.xml' asFileReference humanReadableSize ? Cheers, Doru On Tue, Oct 14, 2014 at 2:27 AM, Evan Donahue emdon...@gmail.com mailto:emdon...@gmail.com wrote: Hello, I've run into some odd behavior and wanted to check whether I might be missing something: I have downloaded a copy of the english wikipedia as an xml file and am hoping to (sax) parse it. However, I can't even seem to get pharo to recognize that the file exists. If I open FileSystem disk root in the playground and naigate, attempting to enter the folder containing the (57G) xml file fails with MessageNotUnderstood: FalsehumanReadableSIByteSize. Likewise if I get a FileReference with FileSystem disk root / 'path' / 'to' / 'file' then self exists returns false and the parser fails. Am I doing something wrong? Should I be able to do this? The version number is #40283 Thanks, Evan -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow Which OS ? Can you check with other programs if this file is readable at all? Nicolai -- best, Eliot
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40305 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 1ce6ea: 40305
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 1ce6eaf214fbe614c9ded6f72a2697afb938711d https://github.com/pharo-project/pharo-core/commit/1ce6eaf214fbe614c9ded6f72a2697afb938711d Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-10-15 (Wed, 15 Oct 2014) Changed paths: A Kernel.package/SymbolicBytecode.class/instance/mapping/sourceInterval.st A Kernel.package/SymbolicBytecode.class/instance/mapping/sourceNode.st M Manifest-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForClassOrMethod_.st M NECompletion.package/NOCCompletionTable.class/class/class initialization/initialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script305.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40305.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 40305 13535 Class code wrongly styled in critic browser https://pharo.fogbugz.com/f/cases/13535 14236 add #sourceInterval and #sourceNode to SymbolicBytecode https://pharo.fogbugz.com/f/cases/14236 14238 Replace Announcer#on:send:to:s senders in NECompletion https://pharo.fogbugz.com/f/cases/14238 http://files.pharo.org/image/40/40305.zip
Re: [Pharo-dev] Tests around Pharo
After numerous tries, it was impossible for us to access to smaltalkhub from our university at 11 o'clock, we'll try this evening or next days from our personal connections. -- View this message in context: http://forum.world.st/Tests-around-Pharo-tp4777295p4784680.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] RFB - anyone having that working properly under linux?
Your have to remove RFBSocketwaitForSendDoneFor: It overrides a method in Socket and fixes a few legacy bugs in Squeak but now it breaks RFB. Cheers, Max On 15.10.2014, at 11:52, p...@highoctane.be wrote: Hello, I've been trying to get RFB running in Pharo. So, installation was okay, I updated the Configuration to pick the last change from Damien Cassou. Still, I start the server with: RFBServer current initializePreferences; configureForMemoryConservation; allowEmptyPasswords: false; setFullPassword: 'password'; Clear text passwords... setViewPassword: 'password'; ... urgh! enableLogging: true; enableDebugging: true; start: 0. along with RFBLog dumpLogToTranscript: true. Server loads, starts. Now, when I connect with RealVNC, or TightVNC, or OSX built-in VNC, I get a view of the UI (so, a copy of the framebuffer is sent) image.png The error I get is (as I am in debugging mode): image.png I followed the contexts upwards in the exception to sendData:startingAt:count: image.png I wonder why I do not get the VNC client going on as the first screen is sent properly. TIA Phil
[Pharo-dev] [pharo-project/pharo-core] 768d1a: 40306
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 768d1a710df941b14ecbd149977d06782d928d88 https://github.com/pharo-project/pharo-core/commit/768d1a710df941b14ecbd149977d06782d928d88 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-10-15 (Wed, 15 Oct 2014) Changed paths: M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/blockReturnTop.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/doDup.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/doPop.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/jump_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/jump_if_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/methodReturnConstant_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/methodReturnReceiver.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/methodReturnTop.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/popIntoLiteralVariable_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/popIntoReceiverVariable_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/popIntoRemoteTemp_inVectorAt_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/popIntoTemporaryVariable_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushActiveContext.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushClosureCopyNumCopiedValues_numArgs_blockSize_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushConsArrayWithElements_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushConstant_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushLiteralVariable_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushNewArrayOfSize_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushReceiver.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushReceiverVariable_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushRemoteTemp_inVectorAt_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/pushTemporaryVariable_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/send_super_numArgs_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/storeIntoLiteralVariable_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/storeIntoReceiverVariable_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/storeIntoRemoteTemp_inVectorAt_.st M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction decoding/storeIntoTemporaryVariable_.st A Kernel.package/SymbolicBytecodeBuilder.class/instance/private/addBytecode_.st R Kernel.package/SymbolicBytecodeBuilder.class/instance/private/print_.st A KernelTests.package/BehaviorTest.class/instance/tests/testCompile.st A OpalTools.package/GTBytecodeBrowser.class/README.md A OpalTools.package/GTBytecodeBrowser.class/definition.st A OpalTools.package/GTBytecodeBrowser.class/instance/building/compose.st A OpalTools.package/GTBytecodeBrowser.class/instance/building/sourceIn_.st A OpalTools.package/GTBytecodeBrowser.class/instance/building/treeIn_.st A OpalTools.package/extension/CompiledMethod/instance/gtInspectorSymbolicBytecodeIn_.st A OpalTools.package/extension/SymbolicBytecode/instance/gtInspectorSourceCodeIn_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script306.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40306.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TBehavior.class/instance/accessing/allSlots.st A Traits.package/TBehavior.class/instance/accessing/basicLocalSelectors.st Log Message: --- 40306 14215 Fix for (Behavior new) compile: https://pharo.fogbugz.com/f/cases/14215 14237 SymbolicBytecodeBuilder: rename #print to #addBytecode: https://pharo.fogbugz.com/f/cases/14237 14239 add inspector view for byte code with source highlighting https://pharo.fogbugz.com/f/cases/14239 http://files.pharo.org/image/40/40306.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40306 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] BlockClosure source code
On 14 Oct 2014, at 16:42, Marcus Denker marcus.den...@inria.fr wrote: On 10 Oct 2014, at 12:29, Marcus Denker marcus.den...@inria.fr mailto:marcus.den...@inria.fr wrote: On 10 Oct 2014, at 10:57, Jan Kurš k...@iam.unibe.ch mailto:k...@iam.unibe.ch wrote: Hi All, Thank you for the replies. I see it is not an easy bug to fix. Do you have any idea, when this can be fixed? I will try to fix it next week... Or can you suggest me some other way/workaround, how to get/generate the source code of a block? The old compiler used a hack to decompile blocks for getting a textual representation… one could port the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I actually like the current scheme of using the byte code-offset-to-AST mapping more). step one: A nice tool… GTInspector view of the byte codes that highlights what is thinks is the corresponding code in the source. (This living Bytecode view replaces what before just printed out the #longPrintString of the CompiledMethod): This is now in 4.0 update 306. e.g. inspect OrderedCollection#do: then select the “SymbolicBC” tab, click on a byte code, then select in the second view the “Source” tab. == when moving around the byte code, the text highlights the code that generated the byte code. Marcus
Re: [Pharo-dev] RFB - anyone having that working properly under linux?
Hi, Well, not really that. I removed the method but the symptom remains. Logging gives me: RFBSession running RFBSession send protocol version RFBSession RFB 003.007 RFBSession viewer using protocol 3.7 RFBSession client shared: true RFBSession a RFBSocket[connected] connected RFBSession ignoring request for ZRLE encoding RFBSession rfbEncodingCopyRect RFBSession rfbEncodingTight RFBSession using Hextile encoding RFBSession rfbEncodingQualityLevel 6 RFBSession ignoring unknown encoding: 4294967073 RFBSession rfbEncodingLastRect RFBSession enabling LastRect protocol extension RFBSession rfbEncodingPointerPos RFBSession enabling cursor position updates RFBSession rfbEncodingRichCursor RFBSession enabling full-colour cursor updates RFBSession received rfbSetPixelFormat RFBSession set pixel format: 32bpp, depth 24 LE, true colour 255,255,255 16+8+0 RFBSession colour map a WordArray(16711680 65280 255 0) an IntegerArray(0 0 0 0) RFBSession before color table RFBSession rfbSetPixelFormat done -- added by me. RFB: caught ConnectionClosed: Connection close while waiting for data. RFB: caught ConnectionTimedOut: send data timeout; data not sent Still blocked on that then... What is your log giving? Phil
Re: [Pharo-dev] Tests around Pharo
On 15 oct. 2014, at 12:35, mschepens schepens.math...@gmail.com wrote: After numerous tries, it was impossible for us to access to smaltalkhub from our university at 11 o'clock, we'll try this evening or next days from our personal connections. Hi Mathieu, I teach at M5 this friday morning, so I can come to IAGL room around 12h15 to show you directly if you want. Tell me. Camille -- View this message in context: http://forum.world.st/Tests-around-Pharo-tp4777295p4784680.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Tests around Pharo
On 15 Oct 2014, at 13:52, Christophe Demarey christophe.dema...@inria.fr wrote: Le 15 oct. 2014 à 13:01, Camille Teruel a écrit : On 15 oct. 2014, at 12:35, mschepens schepens.math...@gmail.com wrote: After numerous tries, it was impossible for us to access to smaltalkhub from our university at 11 o'clock, we'll try this evening or next days from our personal connections. Hi Mathieu, I teach at M5 this friday morning, so I can come to IAGL room around 12h15 to show you directly if you want. Tell me. It is just because University blocks all traffic. They need to use an http proxy. I don't know if it is doable from a Pharo image. Sure, it is doable/available/working: System Settings Network Use HTTP proxy... But HTTP Proxies, especially weird or badly configured ones, are a known PITA.
Re: [Pharo-dev] Tests around Pharo
Using *cntlm *Proxy is an option in the cases where normal HTTP Proxy does not work right On Wed, Oct 15, 2014 at 5:26 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 15 Oct 2014, at 13:52, Christophe Demarey christophe.dema...@inria.fr wrote: Le 15 oct. 2014 à 13:01, Camille Teruel a écrit : On 15 oct. 2014, at 12:35, mschepens schepens.math...@gmail.com wrote: After numerous tries, it was impossible for us to access to smaltalkhub from our university at 11 o'clock, we'll try this evening or next days from our personal connections. Hi Mathieu, I teach at M5 this friday morning, so I can come to IAGL room around 12h15 to show you directly if you want. Tell me. It is just because University blocks all traffic. They need to use an http proxy. I don't know if it is doable from a Pharo image. Sure, it is doable/available/working: System Settings Network Use HTTP proxy... But HTTP Proxies, especially weird or badly configured ones, are a known PITA.
Re: [Pharo-dev] creating custom browsers out of GTInspector extensions
Really Cool...! On Wed, Oct 15, 2014 at 11:52 AM, Marcus Denker marcus.den...@inria.fr wrote: On 14 Oct 2014, at 23:26, Tudor Girba tu...@tudorgirba.com wrote: Hi, Now, that more people are playing with the GTInspector, I would like to raise another point that might otherwise go unnoticed: The inspector extensions do not only work in the inspector, but can also be combined in other browsers as well. We could replace (most of) the FileBrowser by GLMPager new with: [ :pager | pager show: [ :composite :file | composite title: file basename. file gtInspectorItemsIn: composite. file gtInspectorContentsIn: composite ]; title: 'FileBrowser' ]; openOn: FileSystem disk workingDirectory Where it replaces FileList linesOfCode == 1075 (plus three more helper classes). Of course this does a little bit more, but most of that is at the wrong spot anyway. (editor for text files, API for file selection on the class side). Marcus
[Pharo-dev] [ANN] New Gold Member LabWare
The Pharo Consortium is very happy to announce that LabWare has joined the Consortium as a Gold Industrial Member. About LabWare: LabWare is recognized as the global leader in providing enterprise scale laboratory automation solutions. Our Enterprise Laboratory Platform combines the award-winning LabWare LIMS™ and LabWare ELN™, a comprehensive and fully integrated Electronic Laboratory Notebook application, which enables companies to optimize compliance, improve quality, increase productivity and reduce costs. LabWare is a full service provider offering software, professional implementation services and validation assistance, training, and world class technical support to ensure our customers get the maximum value from their LabWare products. - LabWare: http://www.labware.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org
Re: [Pharo-dev] BlockClosure source code
Marcus Denker wrote: On 14 Oct 2014, at 16:42, Marcus Denker marcus.den...@inria.fr mailto:marcus.den...@inria.fr wrote: On 10 Oct 2014, at 12:29, Marcus Denker marcus.den...@inria.fr mailto:marcus.den...@inria.fr wrote: On 10 Oct 2014, at 10:57, Jan Kurš k...@iam.unibe.ch mailto:k...@iam.unibe.ch wrote: Hi All, Thank you for the replies. I see it is not an easy bug to fix. Do you have any idea, when this can be fixed? I will try to fix it next week... Or can you suggest me some other way/workaround, how to get/generate the source code of a block? The old compiler used a hack to decompile blocks for getting a textual representation… one could port the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I actually like the current scheme of using the byte code-offset-to-AST mapping more). step one: A nice tool… GTInspector view of the byte codes that highlights what is thinks is the corresponding code in the source. (This living Bytecode view replaces what before just printed out the #longPrintString of the CompiledMethod): This is now in 4.0 update 306. e.g. inspect OrderedCollection#do: then select the “SymbolicBC” tab, click on a byte code, then select in the second view the “Source” tab. == when moving around the byte code, the text highlights the code that generated the byte code. Marcus This is be great to pull more people into understanding (and helping) the dark depths. What about a tab in the second pane named Help that describes what each bytecode does? (half serious) For example, line 32, what is the 2 in pushTemp: 2, and 1 in pushConstant: 1. cheers -ben
Re: [Pharo-dev] BlockClosure source code
Le 15 oct. 2014 à 14:18, Ben Coman a écrit : Marcus Denker wrote: On 14 Oct 2014, at 16:42, Marcus Denker marcus.den...@inria.fr mailto:marcus.den...@inria.fr wrote: On 10 Oct 2014, at 12:29, Marcus Denker marcus.den...@inria.fr mailto:marcus.den...@inria.fr wrote: On 10 Oct 2014, at 10:57, Jan Kurš k...@iam.unibe.ch mailto:k...@iam.unibe.ch wrote: Hi All, Thank you for the replies. I see it is not an easy bug to fix. Do you have any idea, when this can be fixed? I will try to fix it next week... Or can you suggest me some other way/workaround, how to get/generate the source code of a block? The old compiler used a hack to decompile blocks for getting a textual representation… one could port the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I actually like the current scheme of using the byte code-offset-to-AST mapping more). step one: A nice tool… GTInspector view of the byte codes that highlights what is thinks is the corresponding code in the source. (This living Bytecode view replaces what before just printed out the #longPrintString of the CompiledMethod): This is now in 4.0 update 306. e.g. inspect OrderedCollection#do: then select the “SymbolicBC” tab, click on a byte code, then select in the second view the “Source” tab. == when moving around the byte code, the text highlights the code that generated the byte code. Marcus This is be great to pull more people into understanding (and helping) the dark depths. What about a tab in the second pane named Help that describes what each bytecode does? (half serious) For example, line 32, what is the 2 in pushTemp: 2, and 1 in pushConstant: 1. the index smime.p7s Description: S/MIME cryptographic signature
[Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello
Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello. I love it when a plan comes together. Many small usability changes were added to GT Tools since they were included in Pharo 4. And a lot of small custom inspector presentations were added. http://youtu.be/rIBbeMdFCys (be sure to select the 720p version) This short screencast shows how to use ZnLogEvents and GT Tools in Pharo 4 to look at the HTTP traffic behing Monticello (more specifically, an MCSmalltalkhubRepository). This demonstrates how simple custom inspectors are combined to form a powerful tool - and how easy it is to learn about what is going on inside Pharo. Sven
[Pharo-dev] CompiledMethodhash can produce clashes
We found an issue where CompiledMethods can produce the same hash event within the same MethodDictionary. Reported here: https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-clashes https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-clashes Cheers, Max
[Pharo-dev] [pharo-project/pharo-core] 436ad6: 40307
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 436ad6373a606492b003f3a2aa13db8772dc9d85 https://github.com/pharo-project/pharo-core/commit/436ad6373a606492b003f3a2aa13db8772dc9d85 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-10-15 (Wed, 15 Oct 2014) Changed paths: M Kernel.package/Behavior.class/class/class initialization/initialize.st A Kernel.package/Behavior.class/class/class initialization/initializeClassProperties.st M Kernel.package/Behavior.class/definition.st A Kernel.package/Behavior.class/instance/accessing-properties/properties.st A Kernel.package/Behavior.class/instance/accessing-properties/removePropertiesIfEmpty.st A KernelTests.package/BehaviorTest.class/instance/test - properties/testPropertyValueAtPut.st A KernelTests.package/BehaviorTest.class/instance/test - properties/testRemoveProperty.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script307.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40307.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TBehavior.class/instance/accessing-properties/properties.st A Traits.package/TBehavior.class/instance/accessing-properties/propertyValueAt_.st A Traits.package/TBehavior.class/instance/accessing-properties/propertyValueAt_ifAbsent_.st A Traits.package/TBehavior.class/instance/accessing-properties/propertyValueAt_put_.st A Traits.package/TBehavior.class/instance/accessing-properties/removePropertiesIfEmpty.st A Traits.package/TBehavior.class/instance/accessing-properties/removeProperty_.st A Traits.package/TBehavior.class/instance/accessing-properties/removeProperty_ifAbsent_.st A Traits.package/TraitBehavior.class/class/initialization/initialize.st M Traits.package/TraitBehavior.class/definition.st A Traits.package/TraitBehavior.class/instance/accessing-properties/properties.st A Traits.package/TraitBehavior.class/instance/accessing-properties/removePropertiesIfEmpty.st Log Message: --- 40307 14177 Add properties to classes https://pharo.fogbugz.com/f/cases/14177 http://files.pharo.org/image/40/40307.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40307 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] creating custom browsers out of GTInspector extensions
Le 14/10/2014 23:26, Tudor Girba a écrit : Now, that more people are playing with the GTInspector, I would like to raise another point that might otherwise go unnoticed: The inspector extensions do not only work in the inspector, but can also be combined in other browsers as well. It really looks intersting! I can imagine some good use of it to navigate in geometric objects. Thanks Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
[Pharo-dev] [Pharo4] Properties for classes
Hi, Methods, AST Nodes and all Ring Definitions can store properties. Now in Pharo4 update 307, Yuriy Tymchuk extended this idea to Behaviors. They are not stored when saving code (filing out or MC), as this would be on top (as are the Pragmas on Methods build on top of properties). TODO - unify API across RB/CompiledMethod/Ring - add properties to the Variable meta-objects (there is already a proof-of-concept in class LinkWrapper for one special kind of property) - For sure there are bugs (while writing this I had one idea of one already… need to check) This will not be used by the system itself for now, therefore we opted to store them not in an ivar but a classVar dictionary, so they do not take any space when not used (like CompiledMethod properties where realised in the beginning, too). Marcus
[Pharo-dev] Context variables?
I remember there was some discussion on the list about support for variables tied to the context rather than to the instance or class. This seems particularly useful for a web application where you might want to access the request and response from the context. What is the proper name for these kind of variables and where can I read about how to use them? Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] Context variables?
Hi Jeff, I think you should look at DynamicVariable and ProcessSpecificVariable classes. The first one is a read-only while the second is writable. You have to subclass these class for each variable you want. Ex: DynamicVariable subclass: #MyVar. MyVar value: 4 during: [ MyVar value ] HTH, Camiile On 15 oct. 2014, at 17:09, J.F. Rick s...@je77.com wrote: I remember there was some discussion on the list about support for variables tied to the context rather than to the instance or class. This seems particularly useful for a web application where you might want to access the request and response from the context. What is the proper name for these kind of variables and where can I read about how to use them? Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] CompiledMethodhash can produce clashes
I responded... On Wed, Oct 15, 2014 at 7:11 AM, Max Leske maxle...@gmail.com wrote: We found an issue where CompiledMethods can produce the same hash event within the same MethodDictionary. Reported here: https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-clashes Cheers, Max -- best, Eliot
Re: [Pharo-dev] CompiledMethodhash can produce clashes
Eliot Miranda-2 wrote I responded... I have to disagree with your recommendation. You say that you intend #= to mean has the same effect as rather than is the same as. One of the best things about Smalltalk is how easily we can say what we mean. I think you would be better off creating a method named something like #hasSameEffectAs: to answer what you are presently using #= to do, and change #= to answer the, in my opinion, more sensible is the same as that we conventionally think of #= meaning. $0.02 worth and worth everything you paid for it. :-) Richard -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784771.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] CompiledMethodhash can produce clashes
Hi Richard, On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent richard.sarg...@gemtalksystems.com wrote: Eliot Miranda-2 wrote I responded... I have to disagree with your recommendation. You say that you intend #= to mean has the same effect as rather than is the same as. One of the best things about Smalltalk is how easily we can say what we mean. I think you would be better off creating a method named something like #hasSameEffectAs: to answer what you are presently using #= to do, and change #= to answer the, in my opinion, more sensible is the same as that we conventionally think of #= meaning. But that's the point. #= has to mean something and having it mean #== isn't useful, so one has to choose some value-based semantic for CompiledMethod#= and the one that's there is useful. Defining what #= means for some value type is far easier than defining what it might mean for something as complex as a CompiledMethod. The definition in Squeak/Pharo has been useful to me in implementing a closure-based system, so I'm unapologetic about the current definition. It is a good one but it doesn't preclude defining others. $0.02 worth and worth everything you paid for it. :-) Richard -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784771.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- best, Eliot
Re: [Pharo-dev] CompiledMethodhash can produce clashes
Eliot Miranda-2 wrote On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent richard.sargent@ wrote: One of the best things about Smalltalk is how easily we can say what we mean. I think you would be better off creating a method named something like #hasSameEffectAs: to answer what you are presently using #= to do, and change #= to answer the, in my opinion, more sensible is the same as that we conventionally think of #= meaning. But that's the point. #= has to mean something and having it mean #== isn't useful, so one has to choose some value-based semantic for CompiledMethod#= and the one that's there is useful. Defining what #= means for some value type is far easier than defining what it might mean for something as complex as a CompiledMethod. The definition in Squeak/Pharo has been useful to me in implementing a closure-based system, so I'm unapologetic about the current definition. It is a good one but it doesn't preclude defining others. An interesting response. You ignored the point that e.g. #hasSameEffectAs: provides greater clarity and add an argument against something I didn't say. I also don't think defining equality for a CompiledMethod is particularly difficult. If I were to recompile a method's source code, I would get a new instance of a CompiledMethod that would, in my opinion, be equal to the one already installed in the class (and perhaps cached in the VM's optimizations). So one would be able to say that we would not replace an existing CompiledMethod with an equal one. The current implementation of #= has no such characteristic, since it proclaims a CompiledMethod named #a to be equal to one named #z. The blue book say #= means Answer whether the receiver and the argument represent the same component. The current implementation does so only for some, in my opinion, counter-intuitive definition of same component. -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello
Nice! :) Doru On Wed, Oct 15, 2014 at 3:55 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello. I love it when a plan comes together. Many small usability changes were added to GT Tools since they were included in Pharo 4. And a lot of small custom inspector presentations were added. http://youtu.be/rIBbeMdFCys (be sure to select the 720p version) This short screencast shows how to use ZnLogEvents and GT Tools in Pharo 4 to look at the HTTP traffic behing Monticello (more specifically, an MCSmalltalkhubRepository). This demonstrates how simple custom inspectors are combined to form a powerful tool - and how easy it is to learn about what is going on inside Pharo. Sven -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] CompiledMethodhash can produce clashes
On Wed, Oct 15, 2014 at 11:53 AM, Richard Sargent richard.sarg...@gemtalksystems.com wrote: Eliot Miranda-2 wrote On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent richard.sargent@ wrote: One of the best things about Smalltalk is how easily we can say what we mean. I think you would be better off creating a method named something like #hasSameEffectAs: to answer what you are presently using #= to do, and change #= to answer the, in my opinion, more sensible is the same as that we conventionally think of #= meaning. But that's the point. #= has to mean something and having it mean #== isn't useful, so one has to choose some value-based semantic for CompiledMethod#= and the one that's there is useful. Defining what #= means for some value type is far easier than defining what it might mean for something as complex as a CompiledMethod. The definition in Squeak/Pharo has been useful to me in implementing a closure-based system, so I'm unapologetic about the current definition. It is a good one but it doesn't preclude defining others. An interesting response. You ignored the point that e.g. #hasSameEffectAs: provides greater clarity and add an argument against something I didn't say. It's a given. But the selector still isn't perfectly informative, see below. And what's the effect? The effect when executed, so why not hasSameEffectWhenExecuted:? It's a mouthful. I also don't think defining equality for a CompiledMethod is particularly difficult. If I were to recompile a method's source code, I would get a new instance of a CompiledMethod that would, in my opinion, be equal to the one already installed in the class (and perhaps cached in the VM's optimizations). So one would be able to say that we would not replace an existing CompiledMethod with an equal one. The current implementation of #= has no such characteristic, since it proclaims a CompiledMethod named #a to be equal to one named #z. And for some uses that is correct, one names a /is/ equal to one named z, even though their selectors differ. For example if you do the following: aClass compile: 'a ^1'; compile: 'b ^ 1'. aClass compiledMethodAt: #a put: aClass #b then aClass new a still answers 1. It's only if one introspects (thisContext method selector, opens the debugger, etc) that one sees that the selector doesn't match. If you go back to Smalltalk-80 you'll see that compiled methods didn't store their selector and to find out their selector one searched the method dictionary of the method's method class. As far as what most methods do (excluding introspecting code) the selector is merely a cache of the key in the relevant method dictionary. So #hasSameEffect: *doesn't* mean what one might think it means for some uses (it doesn't only depend on the method in question, but on usage, whether the method is used in an introspective context, etc). So naming a more explanatory selector is more difficult than you might think. The blue book say #= means Answer whether the receiver and the argument represent the same component. The current implementation does so only for some, in my opinion, counter-intuitive definition of same component. Well Smalltalk-80 says Answer true if the receiver and the argument represent the same object and false otherwise. If = is redefined in any subclass, consider also redefining the message hash. and that's just as vague (AFAIA the blue book doesn't define what a component is), because whether objects are equal or not depends on usage. In the end the system is full of definitions of #= which are more or less generally useful in various contexts. Things are easy for the arithmetic types, but for more complex objects there are always caveats | s1 s2 | s1 := Set new. s1 add: s1. s2 := Set new. s2 add: s2. s1 = s2 doesn't terminate. So should Set's #= be called isEqualIfNonRecursive: ? No. Its limited #= is fine in practice and much better than Smalltalk-80's original fall back to #==. But it is not a perfect equality. Neither is CompiledMethod's. But it being imperfect is not an argument for changing it to another, inevitably also flawed definition without good reason. -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- best, Eliot
Re: [Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello
Nice! I'll try the Announcers thing on a Seaside session. How would you do that? I mean DynamicVariables in GT. Phil
Re: [Pharo-dev] Tests around Pharo
I finally managed the proxy problem by sending commits from my own web connection. So I put the issues to Fix review needed. I had some problems while importing Collections-Tests (Native part, for the FloatArrayTest) but finally managed it too. I sent to Damien Cassou the license agreements filled and signed, I will give him my copy of this paper next wednesday. Hope our tests will be helpful and will increase test coverage of pharo, it was really interesting for us to work on this project, and we acquired significant knowledges (about smalltalk but about opensource projects too). We'll follow our commits evolution, and again thanks to all of you for the time you gave us ! -- View this message in context: http://forum.world.st/Tests-around-Pharo-tp4777295p4784793.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello
On 15 Oct 2014, at 21:57, p...@highoctane.be wrote: Nice! I'll try the Announcers thing on a Seaside session. How would you do that? I mean DynamicVariables in GT. Phil I am not sure I understand the question. I did/do Announcement based logging in Seaside, just firing them globally. But I did add a session ID to each log event so that you can keep them apart. My custom WASession subclass adds its #key and #username to the log event objects. I'll send you some example output in private. Sven
Re: [Pharo-dev] OSProcess in 3.0
On Tue, Oct 14, 2014 at 09:35:44PM +0200, Thierry Goubier wrote: Le 14/10/2014 14:15, David T. Lewis a ?crit : On Tue, Oct 14, 2014 at 07:19:10AM +0200, Thierry Goubier wrote: Hi Dave, took me a while to do some testing. It seems there is an issue, but I couldn't find out where. First, the data: Loading a package from a local gitfiletree repository (get from the command a zipped git archive containing the package) : 4.5.11, 4.6.8: 2132 msec. 4.5.12, 4.6.9: 50847 msec. I tried to rewrite the main command, remove the closePipes, etc... No change in the runtime, so your right. Profiling doesn't help much: execution time is mostly idle time (but with a significant increase on PipeableOSProcess commands: goes from invisible to 2700 ms. A user break in the middle shows it delay waiting on output of the external process). Only hint I could see is that it seems to be linked with the size of the output of the command. Thierry, Aha! I am quite sure that you have located the problem. There must be something preventing the OS process from running to completion with a larger amount of output data. It definitely sounds like a bug in my latest update to Pipeable OSProcess. The strange thing is that it runs to completion (i.e. I got no errors; if any data was missing or corrupted on output, my load would fail); but a lot slower than it should be. Thank you very much for finding this. I will get it fixed as quickly as I can. Thanks. I'm unable to help you much, I'm afraid :( Thierry, I do not yet have a solution to this, but I have been able to confirm that the performance difference that you see is primarily associated with the AioPlugin not being present in your VM. When I changed PipeableOSProcess to handle pipe handle closing properly, I used a buffered output stream that is driven by aio events. When data is available to be read from the external OS process, an aio notification pulls the available data into the buffered stream, and when no more data is available, the pipe (file) handles are closed. If the plugin is not present in the VM, I provided a polling mechanism to read data from the external OS process. Apparently this is very inefficient, and I am sure it could be greatly improved. That is the cause of the extremely slow performance that you are seeing. So in summary: The enhancement to PipeableOSProcess relies on an aio event driven reader, and if the AIO plugin is missing, the fallback code relies on polling, and is horribly inefficient. More to follow, and thank you again for identifying the problem. If you can convice your VM vendor to include AioPlugin in your VM, that would be helpful also ;-) Dave
