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

Re: [Pharo-dev] Faster ThreadSafeTranscript Re: [pharo-project/pharo-core] 06d05b: 40165

by Eliot Miranda

On Tue, Aug 12, 2014 at 5:27 AM, Ben Coman <btc(a)openinworld.com> wrote: > GitHub wrote: > > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 06d05bd822deee4a79736d9f99d4a666ca1637eb > https://github.com/pharo-project/pharo-core/commit/06d05bd822deee4a79736d9f… > Author: Jenkins Build Server <board(a)pharo-project.org> <board(a)pharo-project.org> > Date: 2014-08-11 (Mon, 11 Aug 2014) > > > 13806 Remove ThreadSafeTranscriptPluggableTextMorph > https://pharo.fogbugz.com/f/cases/13806 > > > > For anyone concerned about the performance of writing to Transcript from > higher priority threads, just reporting that altering ThreadSafeTranscript > to be safe for Morphic without ThreadSafeTranscriptPluggableTextMorph had a > side effect of enhancing performance by 25x. With two runs of the > following script... > > Smalltalk garbageCollect. > Transcript open. "close after each run" > [ Transcript crShow: ( > [ > | string | > string := '-'. > 1 to: 2000 do: > [ :n | > string := string , '-', n printString. > Transcript show: string. > ]. > (Delay forMilliseconds: 10) wait. > ]) timeToRun. > ] forkAt: 41. > > > > Build 40162 reports timeToRun of 0:00:00:02.483 & 0:00:00:02.451 > Build 40165 reports timeToRun of 0:00:00:00.037 & 0:00:00:00.099 > > > Now I had meant to ask... I notice that FLFuelCommandLineHandler installs > ThreadSafeTranscript, so I wonder it is affected by this change. Can some > Fuel experts comment? > > > Also I am looking for some advice for a minor downside I just noticed. > The whole script above can complete between steps, so the entire output > ends up in the PluggableTextMorph its size without being culled, which > causes making a selection become really slow. Normally the excess text > shown by Transcript is culled in half [1] by > PluggableTextMorph>>appendEntry each time #changed: is called. > > PluggabletextMorph>>appendEntry > "Append the text in the model's writeStream to the editable text. " > textMorph asText size > model characterLimit ifTrue: "<---[0]" > ["Knock off first half of text" > self selectInvisiblyFrom: 1 to: textMorph asText size // 2. > "<---[1]" > self replaceSelectionWith: Text new]. > self selectInvisiblyFrom: textMorph asText size + 1 to: textMorph > asText size. > self replaceSelectionWith: model contents asText. "<----[2]" > self selectInvisiblyFrom: textMorph asText size + 1 to: textMorph > asText size > > That works fine when #appendEntry is being called with lots of small > changes, but for a single large change the entire change ends up in > PluggableTextMorph via [2]. In this case > model characterLimit "--> 20,000" [0] > model contents size "--> 5,671,343" [2] > where model == Transcript. > > So what is the behaviour you'd like to when too much is sent to Transcript? > a. Show all content however briefly. > b. Only the last 20,000 characters are put into the PluggableTextMorph, > and the earlier data thrown away. > I see a few ways to deal with this: > 1. Limit the stream inside Transcript to a maximum 20,000 characters by > basing it on some circular buffer. > 2. Have "Transcript conents" return only the last 20,000 characters of its > stream. > 3. Limit to text sent to #replaceSelectionWith: [2] to 20,000 characters. > > Thoughts anyone? > IMO 20,000 characters is way too little. I routinely set my limit to 200,000. So b) but with a higher limit. a) is pointlessly slow. In your implementation list, surely 2. is the only thing that makes sense? If the limit can remain soft then anyone that wants to see more simply raises their limit. 1. & 3. are implementation details left up to you. As long as the transcript is reasonably fast and has the same protocol as WriteStream (it needs to support printOn: and storeOn: et al) implement it as you will. BTW, the Squeak transcript is appallingly slow. -- best, Eliot

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by Tim Mackinnon

Iâm really in favour of some of the ideas that are coming from this community to make changes. Getting the right balance of productivity and utility is tricky - and Smalltalk environments have got a bit stuck in a rut (although it will be interesting to see some of the presentations at ESUG - the vendors have stuff up there sleeves by the looks of it, and Pharo/Squeak both keep evolving things). In all this change - its also worth remembering what things worked (Iâve been struck recently using a very early Squeak, that there were actually some really good ideas that have gotten lost). My worry with tracing how developers are currently using Pharo is that they are actually forced to use it badly today. Iâm not sure how you get around this (compare usage of different IDEâs? across different languages?). So I donât want to be a downer - and when Iâm better at using Pharo Iâll certainly consider installing DFlow, but that the moment Iâm just struggling too much to be efficient (particularly compared to other language IDEâs, and even some of the older smalltalk IDEâs). Things that stand out for me at the moment - navigating between windows is very clunky ( alt-tab doesnât work how I expect it to work - I want last used ordering, not order opened ordering). I severely miss having a tabbed browser and a way to traverse methods in a transaction of tabs in that browser. The source pane and how it doesnât seem to use the AST and where your cursor is to intelligently do things is also quite clunky. Comparing code changes is also quite tedious. But I know these things are getting easier - so there is some light in the tunnel!!! I really like the possibilities Doru mentions - custom inspectors and debuggers to make my tools more comfortable (and the small amount of code to do this is definitely a smalltalk advantage over the eclipse/intellij plugin systems that are so complicated). Anyway - Iâm looking forward to finding out more at ESUG and then maybe I will get sold on the adaptive idea? Tim On 12 Aug 2014, at 14:31, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi, > > I agree with you Kilon, thanks for your observation (and future help). > > My interaction profiler is only a means to the end. As Doru is saying, my goal is to use the data captured by > DFlow to understand how developers work and what they need in their context. > > In the short term I want to analyze how developers work, but then I will do my best to bridge the gap between > what our IDEs offer and what we need. > > P.s. Thanks Doru for your support! > > Cheers, > Roby > > On Aug 12, 2014, at 2:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Kilon, >> >> Excellent observation! >> >> The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is simple: make it dead cheap for the developer to mold the IDE to his/her contextual needs. >> >> Until now, we have announced an inspector and a debugger that do just that. The inspector makes it possible to mold the tool for every little object if you desire. For example, I alone have built literally hundreds of extensions for various objects. Actually, the inspector goes as far as to allow you to mold the flow to the context in which you are. The debugger lets you define custom debuggers that you can switch to while debugging. All these extensions are incredibly small (an object inspector extension has an average of 8 lines, and the debuggers we implemented consist of a couple of hundred loc), they are independent of each other, and they are put together through a small frame. Add to that the potential of using multiple rendering engines and we get a brand new philosophy that I believe holds the potential to change software development significantly. >> >> This is not a far goal. It's a reality now. At ESUG, we will show how these tools work now in practice. >> >> What Roberto is doing is complementary to our efforts. Data mining will certainly play a significant role in this picture, precisely when we will start to have thousands of these little contextual tools. At this time, DFlow is experimental, but eventually a tool like this should become part of the IDE as we need to understand how developers work in their context and what they need in their context. That is why his effort should be supported by our community. Please install it and give feedback. >> >> Cheers, >> Doru >> >> >> >> >> On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> wrote: >> I think the future are tools tailor made for specific kind of tasks . The age of IDEs and Languages has come to an end. Neither programming languages and IDEs can maintain the complexity of modern software. They are too generic.I think that what we need is a UNIX system but with GUIs , a collection of tools that can talk to each other but at the same time have an extremely limited scope as tools. Smalltalk definitely moves towards that direction but even Smalltalk is far from that goal. >> >> I see that paradigm a lot in 3d art, it raises the amount of knowledge required because you end up with learning hundreds of tools contained in a single application but if you want professional results and you are dead serious about efficiency and productivity then its the way to go. >> >> I will install DFlow and help you in your saga, but bare in mind that DFlow will tell you what I use and I how , but it wont answer you the most important question "what I want to use and how I want to use it" . >> >> >> On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: >> Hi guys, >> >> I uploaded a web page to explain Self-Adaptive IDEs, the vision I will develop for my Ph.D >> http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. >> >> Please take a minute to look at it and tell me your opinion! >> >> At the moment we are conducting an experiment with my interaction profiler (DFlow). It would be >> great if you could participate! This will cost you little effort but help me to gather an understanding >> of development practices and interactions. This is the ground for improving our Pharo IDE! >> >> Cheers and thanks in advance, >> Roberto >> >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > >

Aug. 12, 2014

[pharo-project/pharo-core]

by GitHub

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

Aug. 12, 2014

[pharo-project/pharo-core] 7a5676: 40167

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 7a567698bb633ab7c6be324028eef54b64ee38ee https://github.com/pharo-project/pharo-core/commit/7a567698bb633ab7c6be3240… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-12 (Tue, 12 Aug 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script167.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40167.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Zinc-Character-Encoding-Core.package/ZnCharacterEncoder.class/class/accessing/default.st M Zinc-Character-Encoding-Core.package/ZnCharacterEncoder.class/class/instance creation/newForEncoding_.st A Zinc-Character-Encoding-Core.package/ZnDefaultCharacterEncoder.class/README.md A Zinc-Character-Encoding-Core.package/ZnDefaultCharacterEncoder.class/definition.st M Zinc-Character-Encoding-Core.package/ZnUTF8Encoder.class/instance/converting/nextPut_toStream_.st A Zinc-Character-Encoding-Tests.package/ZnCharacterEncoderTests.class/instance/testing/testDefault.st A Zinc-Character-Encoding-Tests.package/ZnCharacterEncoderTests.class/instance/testing/testUTF8Boundaries.st M Zinc-HTTP.package/ZnApplicationFormUrlEncodedEntity.class/instance/writing/writeRepresentationOn_.st M Zinc-HTTP.package/ZnClient.class/definition.st A Zinc-HTTP.package/ZnClient.class/instance/cleanup/close.st A Zinc-HTTP.package/ZnClient.class/instance/initialization/debugPolicy.st M Zinc-HTTP.package/ZnClient.class/instance/initialization/initialize.st A Zinc-HTTP.package/ZnClient.class/instance/initialization/interactivePolicy.st A Zinc-HTTP.package/ZnClient.class/instance/initialization/systemPolicy.st R Zinc-HTTP.package/ZnClient.class/instance/initialize-release/close.st R Zinc-HTTP.package/ZnClient.class/instance/initialize-release/debugPolicy.st R Zinc-HTTP.package/ZnClient.class/instance/initialize-release/interactivePolicy.st R Zinc-HTTP.package/ZnClient.class/instance/initialize-release/systemPolicy.st A Zinc-HTTP.package/ZnClient.class/instance/logging/logLevel_.st R Zinc-HTTP.package/ZnClient.class/instance/logging/logRequest.st R Zinc-HTTP.package/ZnClient.class/instance/logging/logRequestResponseStarted_.st R Zinc-HTTP.package/ZnClient.class/instance/logging/logResponse.st M Zinc-HTTP.package/ZnClient.class/instance/logging/logToTranscript.st A Zinc-HTTP.package/ZnClient.class/instance/logging/loggingOff.st A Zinc-HTTP.package/ZnClient.class/instance/logging/loggingOn.st R Zinc-HTTP.package/ZnClient.class/instance/logging/stopLogging.st R Zinc-HTTP.package/ZnClient.class/instance/notifications/noteIgnoringExceptionOnReusedConnection_.st R Zinc-HTTP.package/ZnClient.class/instance/notifications/noteRedirect_.st R Zinc-HTTP.package/ZnClient.class/instance/notifications/noteRetrying_.st M Zinc-HTTP.package/ZnClient.class/instance/operations/execute.st A Zinc-HTTP.package/ZnClient.class/instance/options/clientId.st A Zinc-HTTP.package/ZnClient.class/instance/options/clientId_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/logClientTransactionRequestDuration_responseDuration_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/logConnectionClosedAddress_port_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/logConnectionEstablishedTo_started_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/logIgnoringExceptionOnReusedConnection_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/logRedirect_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/logRequestWrittenStarted_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/logResponseReadStarted_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/logRetrying_.st A Zinc-HTTP.package/ZnClient.class/instance/private logging/newLogEvent_.st M Zinc-HTTP.package/ZnClient.class/instance/private protocol/executeRequestResponse.st M Zinc-HTTP.package/ZnClient.class/instance/private protocol/executeWithRetriesRemaining_.st M Zinc-HTTP.package/ZnClient.class/instance/private protocol/getConnectionAndExecute.st M Zinc-HTTP.package/ZnClient.class/instance/private protocol/handleResponse.st M Zinc-HTTP.package/ZnClient.class/instance/private protocol/handleRetry_.st A Zinc-HTTP.package/ZnClient.class/instance/private protocol/prepareNextRequest.st M Zinc-HTTP.package/ZnClient.class/instance/private protocol/prepareRedirect.st A Zinc-HTTP.package/ZnClient.class/instance/private protocol/readResponse.st A Zinc-HTTP.package/ZnClient.class/instance/private protocol/writeRequest.st R Zinc-HTTP.package/ZnClient.class/instance/private/log.st A Zinc-HTTP.package/ZnClient.class/instance/private/newConnectionTo_.st M Zinc-HTTP.package/ZnClient.class/instance/private/receiveCookies.st A Zinc-HTTP.package/ZnClient.class/instance/private/retryExceptionSet.st M Zinc-HTTP.package/ZnClient.class/instance/private/sendCookies.st A Zinc-HTTP.package/ZnClient.class/instance/private/signalHTTPProgress_.st A Zinc-HTTP.package/ZnClientConnectionClosedEvent.class/README.md A Zinc-HTTP.package/ZnClientConnectionClosedEvent.class/definition.st A Zinc-HTTP.package/ZnClientConnectionClosedEvent.class/instance/accessing/address.st A Zinc-HTTP.package/ZnClientConnectionClosedEvent.class/instance/accessing/address_.st A Zinc-HTTP.package/ZnClientConnectionClosedEvent.class/instance/accessing/port.st A Zinc-HTTP.package/ZnClientConnectionClosedEvent.class/instance/accessing/port_.st A Zinc-HTTP.package/ZnClientConnectionClosedEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnClientFollowingRedirectEvent.class/README.md A Zinc-HTTP.package/ZnClientFollowingRedirectEvent.class/definition.st A Zinc-HTTP.package/ZnClientFollowingRedirectEvent.class/instance/accessing/target.st A Zinc-HTTP.package/ZnClientFollowingRedirectEvent.class/instance/accessing/target_.st A Zinc-HTTP.package/ZnClientFollowingRedirectEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnClientIgnoringExceptionOnConnectionReuseEvent.class/README.md A Zinc-HTTP.package/ZnClientIgnoringExceptionOnConnectionReuseEvent.class/definition.st A Zinc-HTTP.package/ZnClientIgnoringExceptionOnConnectionReuseEvent.class/instance/accessing/exception.st A Zinc-HTTP.package/ZnClientIgnoringExceptionOnConnectionReuseEvent.class/instance/accessing/exception_.st A Zinc-HTTP.package/ZnClientIgnoringExceptionOnConnectionReuseEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnClientLogEvent.class/README.md A Zinc-HTTP.package/ZnClientLogEvent.class/definition.st A Zinc-HTTP.package/ZnClientLogEvent.class/instance/accessing/clientId.st A Zinc-HTTP.package/ZnClientLogEvent.class/instance/accessing/clientId_.st A Zinc-HTTP.package/ZnClientLogEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnClientRetryingEvent.class/README.md A Zinc-HTTP.package/ZnClientRetryingEvent.class/definition.st A Zinc-HTTP.package/ZnClientRetryingEvent.class/instance/accessing/exception.st A Zinc-HTTP.package/ZnClientRetryingEvent.class/instance/accessing/exception_.st A Zinc-HTTP.package/ZnClientRetryingEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/README.md A Zinc-HTTP.package/ZnClientTransactionEvent.class/definition.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/duration.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/request.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/requestDuration.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/requestDuration_.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/request_.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/response.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/responseDuration.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/responseDuration_.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/accessing/response_.st A Zinc-HTTP.package/ZnClientTransactionEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnConnectionAcceptedEvent.class/README.md A Zinc-HTTP.package/ZnConnectionAcceptedEvent.class/definition.st A Zinc-HTTP.package/ZnConnectionAcceptedEvent.class/instance/accessing/address.st A Zinc-HTTP.package/ZnConnectionAcceptedEvent.class/instance/accessing/address_.st A Zinc-HTTP.package/ZnConnectionAcceptedEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/README.md A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/definition.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/accessing/address.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/accessing/address_.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/accessing/duration.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/accessing/duration_.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/accessing/hostname.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/accessing/hostname_.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/accessing/port.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/accessing/port_.st A Zinc-HTTP.package/ZnConnectionEstablishedEvent.class/instance/printing/printContentsOn_.st M Zinc-HTTP.package/ZnConstants.class/class/private/initializeHTTPStatusCodes.st M Zinc-HTTP.package/ZnEasy.class/class/operations/getJpeg_.st M Zinc-HTTP.package/ZnEasy.class/class/operations/getPng_.st M Zinc-HTTP.package/ZnEasy.class/class/operations/get_.st R Zinc-HTTP.package/ZnFileLogger.class/README.md R Zinc-HTTP.package/ZnFileLogger.class/class/instance creation/onFileNamed_.st R Zinc-HTTP.package/ZnFileLogger.class/definition.st R Zinc-HTTP.package/ZnFileLogger.class/instance/accessing/event_.st R Zinc-HTTP.package/ZnFileLogger.class/instance/accessing/pathName.st R Zinc-HTTP.package/ZnFileLogger.class/instance/accessing/stream.st R Zinc-HTTP.package/ZnFileLogger.class/instance/initialize-release/close.st R Zinc-HTTP.package/ZnFileLogger.class/instance/initialize-release/initializeOn_.st R Zinc-HTTP.package/ZnFileLogger.class/instance/initialize-release/open.st R Zinc-HTTP.package/ZnFileLogger.class/instance/printing/printOn_.st R Zinc-HTTP.package/ZnFileLogger.class/instance/private/pathName_.st R Zinc-HTTP.package/ZnFileLogger.class/instance/private/stream_.st A Zinc-HTTP.package/ZnHeaders.class/instance/copying/postCopy.st M Zinc-HTTP.package/ZnHttpRetrieveContents.class/README.md A Zinc-HTTP.package/ZnHttpSaveContentsToFile.class/README.md A Zinc-HTTP.package/ZnHttpSaveContentsToFile.class/class/accessing/operation.st A Zinc-HTTP.package/ZnHttpSaveContentsToFile.class/class/accessing/schemes.st A Zinc-HTTP.package/ZnHttpSaveContentsToFile.class/definition.st A Zinc-HTTP.package/ZnHttpSaveContentsToFile.class/instance/operations/performOperation.st M Zinc-HTTP.package/ZnImageExampleDelegate.class/instance/accessing/downloadPharoLogo.st M Zinc-HTTP.package/ZnLogEvent.class/README.md A Zinc-HTTP.package/ZnLogEvent.class/class/accessing/announcer.st A Zinc-HTTP.package/ZnLogEvent.class/class/accessing/nextId.st A Zinc-HTTP.package/ZnLogEvent.class/class/class initialization/initialize.st A Zinc-HTTP.package/ZnLogEvent.class/class/convenience/logToTranscript.st A Zinc-HTTP.package/ZnLogEvent.class/class/convenience/open.st A Zinc-HTTP.package/ZnLogEvent.class/class/convenience/stopLoggingToTranscript.st R Zinc-HTTP.package/ZnLogEvent.class/class/instance creation/category_message_.st R Zinc-HTTP.package/ZnLogEvent.class/class/instance creation/debug_.st R Zinc-HTTP.package/ZnLogEvent.class/class/instance creation/info_.st R Zinc-HTTP.package/ZnLogEvent.class/class/instance creation/transaction_.st A Zinc-HTTP.package/ZnLogEvent.class/class/system startup/startUp.st M Zinc-HTTP.package/ZnLogEvent.class/definition.st A Zinc-HTTP.package/ZnLogEvent.class/instance/accessing/announcer.st R Zinc-HTTP.package/ZnLogEvent.class/instance/accessing/category.st A Zinc-HTTP.package/ZnLogEvent.class/instance/accessing/id.st R Zinc-HTTP.package/ZnLogEvent.class/instance/accessing/message.st A Zinc-HTTP.package/ZnLogEvent.class/instance/accessing/nextId.st R Zinc-HTTP.package/ZnLogEvent.class/instance/accessing/processId.st R Zinc-HTTP.package/ZnLogEvent.class/instance/accessing/timeStamp.st A Zinc-HTTP.package/ZnLogEvent.class/instance/accessing/timestamp.st A Zinc-HTTP.package/ZnLogEvent.class/instance/actions/emit.st A Zinc-HTTP.package/ZnLogEvent.class/instance/beacon/printOneLineContentsOn_.st A Zinc-HTTP.package/ZnLogEvent.class/instance/beacon/printOneLineOn_.st R Zinc-HTTP.package/ZnLogEvent.class/instance/initialization/initialize.st A Zinc-HTTP.package/ZnLogEvent.class/instance/initialize/initialize.st A Zinc-HTTP.package/ZnLogEvent.class/instance/printing/printContentsOn_.st R Zinc-HTTP.package/ZnLogEvent.class/instance/printing/printHeaderOn_.st M Zinc-HTTP.package/ZnLogEvent.class/instance/printing/printOn_.st R Zinc-HTTP.package/ZnLogEvent.class/instance/private/category_.st R Zinc-HTTP.package/ZnLogEvent.class/instance/private/message_.st R Zinc-HTTP.package/ZnLogEvent.class/instance/private/processId_.st R Zinc-HTTP.package/ZnLogEvent.class/instance/private/timeStamp_.st R Zinc-HTTP.package/ZnLogListener.class/README.md R Zinc-HTTP.package/ZnLogListener.class/definition.st R Zinc-HTTP.package/ZnLogListener.class/instance/accessing/allowAll.st R Zinc-HTTP.package/ZnLogListener.class/instance/accessing/allow_.st R Zinc-HTTP.package/ZnLogListener.class/instance/accessing/enabled.st R Zinc-HTTP.package/ZnLogListener.class/instance/accessing/enabled_.st R Zinc-HTTP.package/ZnLogListener.class/instance/accessing/event_.st R Zinc-HTTP.package/ZnLogListener.class/instance/accessing/filter.st R Zinc-HTTP.package/ZnLogListener.class/instance/accessing/filter_.st R Zinc-HTTP.package/ZnLogListener.class/instance/accessing/handleEvent_.st R Zinc-HTTP.package/ZnLogListener.class/instance/initialization/initialize.st R Zinc-HTTP.package/ZnLogListener.class/instance/private/acceptEvent_.st R Zinc-HTTP.package/ZnLogSupport.class/README.md R Zinc-HTTP.package/ZnLogSupport.class/class/instance creation/newEnabled.st R Zinc-HTTP.package/ZnLogSupport.class/definition.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/addListener_.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/debug_.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/disable.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/enable.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/enabled.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/enabled_.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/info_.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/removeListener_.st R Zinc-HTTP.package/ZnLogSupport.class/instance/accessing/transaction_.st R Zinc-HTTP.package/ZnLogSupport.class/instance/initialization/initialize.st R Zinc-HTTP.package/ZnLogSupport.class/instance/private/announcer.st M Zinc-HTTP.package/ZnManagingMultiThreadedServer.class/instance/private/closeConnections.st M Zinc-HTTP.package/ZnManagingMultiThreadedServer.class/instance/private/closeSocketStream_.st R Zinc-HTTP.package/ZnMemoryLogger.class/README.md R Zinc-HTTP.package/ZnMemoryLogger.class/definition.st R Zinc-HTTP.package/ZnMemoryLogger.class/instance/accessing/event_.st R Zinc-HTTP.package/ZnMemoryLogger.class/instance/accessing/limit.st R Zinc-HTTP.package/ZnMemoryLogger.class/instance/accessing/limit_.st R Zinc-HTTP.package/ZnMemoryLogger.class/instance/accessing/logEvents.st R Zinc-HTTP.package/ZnMemoryLogger.class/instance/initialize-release/clear.st R Zinc-HTTP.package/ZnMemoryLogger.class/instance/private/shrink.st A Zinc-HTTP.package/ZnMessage.class/instance/copying/postCopy.st A Zinc-HTTP.package/ZnMimePart.class/instance/copying/postCopy.st M Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/private/closeSocketStream_.st R Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/private/writeResponseBad_on_.st A Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/private/writeResponseBad_on_timing_.st M Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/request handling/executeOneRequestResponseOn_.st M Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/request handling/executeRequestResponseLoopOn_.st R Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/request handling/readRequestSafely_.st A Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/request handling/readRequestSafely_timing_.st M Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/request handling/serveConnectionsOn_.st R Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/request handling/writeResponseSafely_on_.st A Zinc-HTTP.package/ZnMultiThreadedServer.class/instance/request handling/writeResponseSafely_on_timing_.st M Zinc-HTTP.package/ZnNetworkingUtils.class/instance/proxy/shouldProxyUrl_.st A Zinc-HTTP.package/ZnRequest.class/instance/copying/postCopy.st A Zinc-HTTP.package/ZnRequestLine.class/instance/copying/postCopy.st A Zinc-HTTP.package/ZnRequestReadEvent.class/README.md A Zinc-HTTP.package/ZnRequestReadEvent.class/definition.st A Zinc-HTTP.package/ZnRequestReadEvent.class/instance/accessing/duration.st A Zinc-HTTP.package/ZnRequestReadEvent.class/instance/accessing/duration_.st A Zinc-HTTP.package/ZnRequestReadEvent.class/instance/accessing/request.st A Zinc-HTTP.package/ZnRequestReadEvent.class/instance/accessing/request_.st A Zinc-HTTP.package/ZnRequestReadEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/README.md A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/definition.st A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/instance/accessing/duration.st A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/instance/accessing/duration_.st A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/instance/accessing/request.st A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/instance/accessing/request_.st A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/instance/accessing/response.st A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/instance/accessing/response_.st A Zinc-HTTP.package/ZnRequestResponseHandledEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnRequestWrittenEvent.class/README.md A Zinc-HTTP.package/ZnRequestWrittenEvent.class/definition.st A Zinc-HTTP.package/ZnRequestWrittenEvent.class/instance/accessing/duration.st A Zinc-HTTP.package/ZnRequestWrittenEvent.class/instance/accessing/duration_.st A Zinc-HTTP.package/ZnRequestWrittenEvent.class/instance/accessing/request.st A Zinc-HTTP.package/ZnRequestWrittenEvent.class/instance/accessing/request_.st A Zinc-HTTP.package/ZnRequestWrittenEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnResponse.class/instance/copying/postCopy.st A Zinc-HTTP.package/ZnResponseReadEvent.class/README.md A Zinc-HTTP.package/ZnResponseReadEvent.class/definition.st A Zinc-HTTP.package/ZnResponseReadEvent.class/instance/accessing/duration.st A Zinc-HTTP.package/ZnResponseReadEvent.class/instance/accessing/duration_.st A Zinc-HTTP.package/ZnResponseReadEvent.class/instance/accessing/response.st A Zinc-HTTP.package/ZnResponseReadEvent.class/instance/accessing/response_.st A Zinc-HTTP.package/ZnResponseReadEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnResponseWrittenEvent.class/README.md A Zinc-HTTP.package/ZnResponseWrittenEvent.class/definition.st A Zinc-HTTP.package/ZnResponseWrittenEvent.class/instance/accessing/duration.st A Zinc-HTTP.package/ZnResponseWrittenEvent.class/instance/accessing/duration_.st A Zinc-HTTP.package/ZnResponseWrittenEvent.class/instance/accessing/response.st A Zinc-HTTP.package/ZnResponseWrittenEvent.class/instance/accessing/response_.st A Zinc-HTTP.package/ZnResponseWrittenEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnServerConnectionClosedEvent.class/README.md A Zinc-HTTP.package/ZnServerConnectionClosedEvent.class/definition.st A Zinc-HTTP.package/ZnServerConnectionClosedEvent.class/instance/accessing/address.st A Zinc-HTTP.package/ZnServerConnectionClosedEvent.class/instance/accessing/address_.st A Zinc-HTTP.package/ZnServerConnectionClosedEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnServerErrorEvent.class/README.md A Zinc-HTTP.package/ZnServerErrorEvent.class/definition.st A Zinc-HTTP.package/ZnServerErrorEvent.class/instance/accessing/exception.st A Zinc-HTTP.package/ZnServerErrorEvent.class/instance/accessing/exception_.st A Zinc-HTTP.package/ZnServerGenericLogEvent.class/README.md A Zinc-HTTP.package/ZnServerGenericLogEvent.class/class/instance creation/subject_.st A Zinc-HTTP.package/ZnServerGenericLogEvent.class/definition.st A Zinc-HTTP.package/ZnServerGenericLogEvent.class/instance/accessing/subject.st A Zinc-HTTP.package/ZnServerGenericLogEvent.class/instance/accessing/subject_.st A Zinc-HTTP.package/ZnServerGenericLogEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnServerHandlerErrorEvent.class/README.md A Zinc-HTTP.package/ZnServerHandlerErrorEvent.class/definition.st A Zinc-HTTP.package/ZnServerHandlerErrorEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnServerLogEvent.class/README.md A Zinc-HTTP.package/ZnServerLogEvent.class/definition.st A Zinc-HTTP.package/ZnServerLogEvent.class/instance/accessing/processId.st A Zinc-HTTP.package/ZnServerLogEvent.class/instance/accessing/serverId.st A Zinc-HTTP.package/ZnServerLogEvent.class/instance/initialize/initialize.st A Zinc-HTTP.package/ZnServerLogEvent.class/instance/initialize/processId_.st A Zinc-HTTP.package/ZnServerLogEvent.class/instance/initialize/serverId_.st A Zinc-HTTP.package/ZnServerLogEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnServerReadErrorEvent.class/README.md A Zinc-HTTP.package/ZnServerReadErrorEvent.class/definition.st A Zinc-HTTP.package/ZnServerReadErrorEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnServerSocketBoundEvent.class/README.md A Zinc-HTTP.package/ZnServerSocketBoundEvent.class/definition.st A Zinc-HTTP.package/ZnServerSocketBoundEvent.class/instance/accessing/address.st A Zinc-HTTP.package/ZnServerSocketBoundEvent.class/instance/accessing/address_.st A Zinc-HTTP.package/ZnServerSocketBoundEvent.class/instance/accessing/port.st A Zinc-HTTP.package/ZnServerSocketBoundEvent.class/instance/accessing/port_.st A Zinc-HTTP.package/ZnServerSocketBoundEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnServerSocketReleasedEvent.class/README.md A Zinc-HTTP.package/ZnServerSocketReleasedEvent.class/definition.st A Zinc-HTTP.package/ZnServerSocketReleasedEvent.class/instance/accessing/address.st A Zinc-HTTP.package/ZnServerSocketReleasedEvent.class/instance/accessing/address_.st A Zinc-HTTP.package/ZnServerSocketReleasedEvent.class/instance/accessing/port.st A Zinc-HTTP.package/ZnServerSocketReleasedEvent.class/instance/accessing/port_.st A Zinc-HTTP.package/ZnServerSocketReleasedEvent.class/instance/printing/printContentsOn_.st A Zinc-HTTP.package/ZnServerStartedEvent.class/README.md A Zinc-HTTP.package/ZnServerStartedEvent.class/definition.st A Zinc-HTTP.package/ZnServerStartedEvent.class/instance/accessing/description.st A Zinc-HTTP.package/ZnServerStartedEvent.class/instance/accessing/description_.st A Zinc-HTTP.package/ZnServerStartedEvent.class/instance/printing/printContentsOn_.st Log Message: ----------- 40167 13838 Update Zn+Zdc August 2014 https://pharo.fogbugz.com/f/cases/13838 http://files.pharo.org/image/40/40167.zip

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by Tudor Girba

Hi, On Tue, Aug 12, 2014 at 3:59 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Tudor I think you doing a great job and you are correct that Pharo is > there concerning the goal you describing. But my goal is not the goal you > are describing. My goal is the next step, its the product of your goal. > What happens when you have a mouldable IDE. I am talking about the specific > tools themselves not tools that help create those tools. > I believe we do not contradict each other here. When you have a moldable IDE, you can build your own tools. The prerequisite for these tools to exist is to make it possible for them to exist. This is where our work goes. We want to make it possible for you to make your beloved tools. Until now, it was difficult. Now it is significantly cheaper. You might say that it is still difficult, but here is the thing: most Smalltalk developers have extended Object at least once because it is dead easy to do it. If you ask the Java developers, they will tell you that this is beyond their abilities. Now, we make the same thing for tools, and you will see that people will create their own tools. It's just the point of view that has to change :). > Its the same with 3d graphics apps, no artist want to use graphic engines > to create 3d graphics, they want to use tools that already provide the > means to achieve the result they want. This is why opengl is not enough , > or a graphic engine, or even visual coding environment. > Here is a little detail that I think your are overlooking: the artist is a clicker, and he wants a clicking tool. But, the programmer is a programmer, and before the clicking tool there should exist the possibility of programming the tools. In your previous message you mentioned Unix. Unix relies on exactly the same metaphor by offering the possibility of building tiny tools with a few characters. Once this was available, those tiny tools exploded. In the IDE world, we are still at the level of Windows. We should have Unix and let 1000 flowers blossom :). > For example lets say that I want a tool to visualise structure of objects > and how they depend on each other. I know that I can do that with roassal > but I am not aware if such tool exist already for Pharo. > I do not understand. Roassal already exists for Pharo :). And if you play with the Glamorous Toolkit image, you have it loaded by default. > I would also like another tool that visualizes sockets connection and > communication. Data that comes in Pharo and goes out. > Exactly. Go, build one. This should not be difficult. In my working images, I am surrounded by many such tools. I would also like a drag and drop GUI designer. > That is a bit of a different thing, I believe. I agree that it would be useful. > I would also like a tool, that would allow me to quickly browse through > class comments and edit them and even share them online, like an online > database. > I would be happy to see one of these :). > I would also like code completion that also displays small info about the > code to be completed. > :). > I would also like visual integration of git. Git alone is a huge > collection of tools. > and so on .... > Sure. And? Doru > > On Tue, Aug 12, 2014 at 3:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Kilon, >> >> Excellent observation! >> >> The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is >> simple: make it dead cheap for the developer to mold the IDE to his/her >> contextual needs. >> >> Until now, we have announced an inspector and a debugger that do just >> that. The inspector makes it possible to mold the tool for every little >> object if you desire. For example, I alone have built literally hundreds of >> extensions for various objects. Actually, the inspector goes as far as to >> allow you to mold the flow to the context in which you are. The debugger >> lets you define custom debuggers that you can switch to while debugging. >> All these extensions are incredibly small (an object inspector extension >> has an average of 8 lines, and the debuggers we implemented consist of a >> couple of hundred loc), they are independent of each other, and they are >> put together through a small frame. Add to that the potential of using >> multiple rendering engines and we get a brand new philosophy that I believe >> holds the potential to change software development significantly. >> >> This is not a far goal. It's a reality now. At ESUG, we will show how >> these tools work now in practice. >> >> What Roberto is doing is complementary to our efforts. Data mining will >> certainly play a significant role in this picture, precisely when we will >> start to have thousands of these little contextual tools. At this time, >> DFlow is experimental, but eventually a tool like this should become part >> of the IDE as we need to understand how developers work in their context >> and what they need in their context. That is why his effort should be >> supported by our community. Please install it and give feedback. >> >> Cheers, >> Doru >> >> >> >> >> On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> >> wrote: >> >>> I think the future are tools tailor made for specific kind of tasks . >>> The age of IDEs and Languages has come to an end. Neither programming >>> languages and IDEs can maintain the complexity of modern software. They are >>> too generic.I think that what we need is a UNIX system but with GUIs , a >>> collection of tools that can talk to each other but at the same time have >>> an extremely limited scope as tools. Smalltalk definitely moves towards >>> that direction but even Smalltalk is far from that goal. >>> >>> I see that paradigm a lot in 3d art, it raises the amount of knowledge >>> required because you end up with learning hundreds of tools contained in a >>> single application but if you want professional results and you are dead >>> serious about efficiency and productivity then its the way to go. >>> >>> I will install DFlow and help you in your saga, but bare in mind that >>> DFlow will tell you what I use and I how , but it wont answer you the most >>> important question "what I want to use and how I want to use it" . >>> >>> >>> On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli < >>> roberto.minelli(a)usi.ch> wrote: >>> >>>> Hi guys, >>>> >>>> I uploaded a web page to explain Self-Adaptive IDEs, the vision I will >>>> develop for my Ph.D >>>> http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. >>>> >>>> Please take a minute to look at it and tell me your opinion! >>>> >>>> At the moment we are conducting an experiment with my interaction >>>> profiler (DFlow). It would be >>>> great if you could participate! This will cost you little effort but >>>> help me to gather an understanding >>>> of development practices and interactions. This is the ground for >>>> improving our Pharo IDE! >>>> >>>> Cheers and thanks in advance, >>>> Roberto >>>> >>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 12, 2014

Re: [Pharo-dev] Adding menu to ListModel

by Benjamin

I answered again. Short version: could you report an issue here https://github.com/spec-framework/spec/issues Thanks, Ben On 12 Aug 2014, at 15:14, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > So Ben answered my question: http://stackoverflow.com/a/25242253/982238 > > but with his approach I get MenuMorph(Object)>>doesNotUnderstand: #addGroup:. Any ideas why? > > Uko > > On 11 Aug 2014, at 12:17, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Hi guys. >> >> I need a little help with adding a menu to the ListModel (in Spec). Can you take a look please: http://stackoverflow.com/questions/25240931/add-menu-to-listmodel >> >> Cheers. >> Uko >

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by kilon alios

Tudor I think you doing a great job and you are correct that Pharo is there concerning the goal you describing. But my goal is not the goal you are describing. My goal is the next step, its the product of your goal. What happens when you have a mouldable IDE. I am talking about the specific tools themselves not tools that help create those tools. Its the same with 3d graphics apps, no artist want to use graphic engines to create 3d graphics, they want to use tools that already provide the means to achieve the result they want. This is why opengl is not enough , or a graphic engine, or even visual coding environment. For example lets say that I want a tool to visualise structure of objects and how they depend on each other. I know that I can do that with roassal but I am not aware if such tool exist already for Pharo. I would also like another tool that visualizes sockets connection and communication. Data that comes in Pharo and goes out. I would also like a drag and drop GUI designer. I would also like a tool, that would allow me to quickly browse through class comments and edit them and even share them online, like an online database. I would also like code completion that also displays small info about the code to be completed. I would also like visual integration of git. Git alone is a huge collection of tools. and so on .... On Tue, Aug 12, 2014 at 3:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Kilon, > > Excellent observation! > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is > simple: make it dead cheap for the developer to mold the IDE to his/her > contextual needs. > > Until now, we have announced an inspector and a debugger that do just > that. The inspector makes it possible to mold the tool for every little > object if you desire. For example, I alone have built literally hundreds of > extensions for various objects. Actually, the inspector goes as far as to > allow you to mold the flow to the context in which you are. The debugger > lets you define custom debuggers that you can switch to while debugging. > All these extensions are incredibly small (an object inspector extension > has an average of 8 lines, and the debuggers we implemented consist of a > couple of hundred loc), they are independent of each other, and they are > put together through a small frame. Add to that the potential of using > multiple rendering engines and we get a brand new philosophy that I believe > holds the potential to change software development significantly. > > This is not a far goal. It's a reality now. At ESUG, we will show how > these tools work now in practice. > > What Roberto is doing is complementary to our efforts. Data mining will > certainly play a significant role in this picture, precisely when we will > start to have thousands of these little contextual tools. At this time, > DFlow is experimental, but eventually a tool like this should become part > of the IDE as we need to understand how developers work in their context > and what they need in their context. That is why his effort should be > supported by our community. Please install it and give feedback. > > Cheers, > Doru > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> I think the future are tools tailor made for specific kind of tasks . The >> age of IDEs and Languages has come to an end. Neither programming languages >> and IDEs can maintain the complexity of modern software. They are too >> generic.I think that what we need is a UNIX system but with GUIs , a >> collection of tools that can talk to each other but at the same time have >> an extremely limited scope as tools. Smalltalk definitely moves towards >> that direction but even Smalltalk is far from that goal. >> >> I see that paradigm a lot in 3d art, it raises the amount of knowledge >> required because you end up with learning hundreds of tools contained in a >> single application but if you want professional results and you are dead >> serious about efficiency and productivity then its the way to go. >> >> I will install DFlow and help you in your saga, but bare in mind that >> DFlow will tell you what I use and I how , but it wont answer you the most >> important question "what I want to use and how I want to use it" . >> >> >> On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch >> > wrote: >> >>> Hi guys, >>> >>> I uploaded a web page to explain Self-Adaptive IDEs, the vision I will >>> develop for my Ph.D >>> http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. >>> >>> Please take a minute to look at it and tell me your opinion! >>> >>> At the moment we are conducting an experiment with my interaction >>> profiler (DFlow). It would be >>> great if you could participate! This will cost you little effort but >>> help me to gather an understanding >>> of development practices and interactions. This is the ground for >>> improving our Pharo IDE! >>> >>> Cheers and thanks in advance, >>> Roberto >>> >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 12, 2014

Re: [Pharo-dev] About STON

by Sven Van Caekenberghe

Stef, On 12 Aug 2014, at 07:55, stepharo <stepharo(a)free.fr> wrote: > sven > > I was wondering if we could get the following in STON > > > STON acceptNonPresentClasses. > > STON readFrom: 'Blblbl {#foo : 3} > > would create a dictionary with class name -> #Blblbl > > Now if the class is loaded we would get a Blblbl object Good idea: === Name: STON-Core-SvenVanCaekenberghe.51 Author: SvenVanCaekenberghe Time: 12 August 2014, 3:40:21.574545 pm UUID: 6559f648-b74a-4901-b249-e72808fdea0d Ancestors: STON-Core-SvenVanCaekenberghe.49 Add STONReader>#acceptUnknownClasses: option When true (default is false) an unknown object class will result in a map with an added property #className (thx StÃ©phane Ducasse for the suggetion) Added STON class>>#classNameKey Moved #stonName from Class to Object class Added STONReaderTests>>#testUnknownClasses === Name: STON-Tests-SvenVanCaekenberghe.46 Author: SvenVanCaekenberghe Time: 12 August 2014, 3:40:43.256364 pm UUID: e48a3d7c-6d8a-4899-943f-829ee4e8715d Ancestors: STON-Tests-SvenVanCaekenberghe.44 Add STONReader>#acceptUnknownClasses: option When true (default is false) an unknown object class will result in a map with an added property #className (thx StÃ©phane Ducasse for the suggetion) Added STON class>>#classNameKey Moved #stonName from Class to Object class Added STONReaderTests>>#testUnknownClasses === > Christophe has some other ideas such > > STON nilOutEmptyCollections. > to avoid to save #() and other I think this can better be done with a custom serialisation, assuming #roles is a lazy initialised collection, like: #stonOn: stonWriter stonWriter writeObject: self streamMap: [ :stream | stream at: #username put: username; at: #password put: password. (roles isNil or: [ roles isEmpty ]) ifFalse: [ stream at: #roles put: roles ] ] BTW, not writing nil is already an option, see #stonShouldWriteNilInstVars > Stef Thanks for the feedback, Sven

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by kilon alios

I have enabled your DFlow tool, but it looks like it severely slows down Pharo. Browsing through methods was instantaneous but with DFlow I see at least a one second lag which make its use quite an obstacle to my workflow. I am on macos 10.9 maverics with a 2011 macbook air. On Tue, Aug 12, 2014 at 4:31 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi, > > I agree with you Kilon, thanks for your observation (and future help). > > My interaction profiler is only a means to the end. As Doru is saying, my > goal is to use the data captured by > DFlow to understand how developers work and what they need in their > context. > > In the short term I want to analyze how developers work, but then I will > do my best to bridge the gap between > what our IDEs offer and what we need. > > P.s. Thanks Doru for your support! > > Cheers, > Roby > > On Aug 12, 2014, at 2:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi Kilon, > > > > Excellent observation! > > > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is > simple: make it dead cheap for the developer to mold the IDE to his/her > contextual needs. > > > > Until now, we have announced an inspector and a debugger that do just > that. The inspector makes it possible to mold the tool for every little > object if you desire. For example, I alone have built literally hundreds of > extensions for various objects. Actually, the inspector goes as far as to > allow you to mold the flow to the context in which you are. The debugger > lets you define custom debuggers that you can switch to while debugging. > All these extensions are incredibly small (an object inspector extension > has an average of 8 lines, and the debuggers we implemented consist of a > couple of hundred loc), they are independent of each other, and they are > put together through a small frame. Add to that the potential of using > multiple rendering engines and we get a brand new philosophy that I believe > holds the potential to change software development significantly. > > > > This is not a far goal. It's a reality now. At ESUG, we will show how > these tools work now in practice. > > > > What Roberto is doing is complementary to our efforts. Data mining will > certainly play a significant role in this picture, precisely when we will > start to have thousands of these little contextual tools. At this time, > DFlow is experimental, but eventually a tool like this should become part > of the IDE as we need to understand how developers work in their context > and what they need in their context. That is why his effort should be > supported by our community. Please install it and give feedback. > > > > Cheers, > > Doru > > > > > > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > > I think the future are tools tailor made for specific kind of tasks . > The age of IDEs and Languages has come to an end. Neither programming > languages and IDEs can maintain the complexity of modern software. They are > too generic.I think that what we need is a UNIX system but with GUIs , a > collection of tools that can talk to each other but at the same time have > an extremely limited scope as tools. Smalltalk definitely moves towards > that direction but even Smalltalk is far from that goal. > > > > I see that paradigm a lot in 3d art, it raises the amount of knowledge > required because you end up with learning hundreds of tools contained in a > single application but if you want professional results and you are dead > serious about efficiency and productivity then its the way to go. > > > > I will install DFlow and help you in your saga, but bare in mind that > DFlow will tell you what I use and I how , but it wont answer you the most > important question "what I want to use and how I want to use it" . > > > > > > On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli < > roberto.minelli(a)usi.ch> wrote: > > Hi guys, > > > > I uploaded a web page to explain Self-Adaptive IDEs, the vision I will > develop for my Ph.D > > http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. > > > > Please take a minute to look at it and tell me your opinion! > > > > At the moment we are conducting an experiment with my interaction > profiler (DFlow). It would be > > great if you could participate! This will cost you little effort but > help me to gather an understanding > > of development practices and interactions. This is the ground for > improving our Pharo IDE! > > > > Cheers and thanks in advance, > > Roberto > > > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > >

Aug. 12, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by Roberto Minelli

Hi, I agree with you Kilon, thanks for your observation (and future help). My interaction profiler is only a means to the end. As Doru is saying, my goal is to use the data captured by DFlow to understand how developers work and what they need in their context. In the short term I want to analyze how developers work, but then I will do my best to bridge the gap between what our IDEs offer and what we need. P.s. Thanks Doru for your support! Cheers, Roby On Aug 12, 2014, at 2:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Kilon, > > Excellent observation! > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is simple: make it dead cheap for the developer to mold the IDE to his/her contextual needs. > > Until now, we have announced an inspector and a debugger that do just that. The inspector makes it possible to mold the tool for every little object if you desire. For example, I alone have built literally hundreds of extensions for various objects. Actually, the inspector goes as far as to allow you to mold the flow to the context in which you are. The debugger lets you define custom debuggers that you can switch to while debugging. All these extensions are incredibly small (an object inspector extension has an average of 8 lines, and the debuggers we implemented consist of a couple of hundred loc), they are independent of each other, and they are put together through a small frame. Add to that the potential of using multiple rendering engines and we get a brand new philosophy that I believe holds the potential to change software development significantly. > > This is not a far goal. It's a reality now. At ESUG, we will show how these tools work now in practice. > > What Roberto is doing is complementary to our efforts. Data mining will certainly play a significant role in this picture, precisely when we will start to have thousands of these little contextual tools. At this time, DFlow is experimental, but eventually a tool like this should become part of the IDE as we need to understand how developers work in their context and what they need in their context. That is why his effort should be supported by our community. Please install it and give feedback. > > Cheers, > Doru > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I think the future are tools tailor made for specific kind of tasks . The age of IDEs and Languages has come to an end. Neither programming languages and IDEs can maintain the complexity of modern software. They are too generic.I think that what we need is a UNIX system but with GUIs , a collection of tools that can talk to each other but at the same time have an extremely limited scope as tools. Smalltalk definitely moves towards that direction but even Smalltalk is far from that goal. > > I see that paradigm a lot in 3d art, it raises the amount of knowledge required because you end up with learning hundreds of tools contained in a single application but if you want professional results and you are dead serious about efficiency and productivity then its the way to go. > > I will install DFlow and help you in your saga, but bare in mind that DFlow will tell you what I use and I how , but it wont answer you the most important question "what I want to use and how I want to use it" . > > > On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi guys, > > I uploaded a web page to explain Self-Adaptive IDEs, the vision I will develop for my Ph.D > http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. > > Please take a minute to look at it and tell me your opinion! > > At the moment we are conducting an experiment with my interaction profiler (DFlow). It would be > great if you could participate! This will cost you little effort but help me to gather an understanding > of development practices and interactions. This is the ground for improving our Pharo IDE! > > Cheers and thanks in advance, > Roberto > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 12, 2014