- Pharo-dev - lists.pharo.org

PharoV40 sources still broken?

by Nicolai Hess

pharo 4.0 608 with PharoV40 sources: - enter some text in a workspace - select the text - choose "Method source with it" -> RemoteString(Object)>>error: [ filePositionHi > theFile size ifTrue: [ self error: 'RemoteString past end of file' ]. theFile position: filePositionHi. theFile nextChunk ] in RemoteString>>string in Block: [ ... BlockClosure>>ensure: RemoteString>>string ClassOrganization>>comment ClassOrganization>>classComment [ :each | bar current: (count := count + 1). each selectorsDo: [ :sel | ((each sourceCodeAt: sel) includesSubstring: aString caseSensitive: caseSensitive) ifTrue: [ addMethod value: each value: sel ] ]. (each organization classComment asString includesSubstring: aString caseSensitive: caseSensitive) ifTrue: [ addComment value: each ] ] in [ :bar | | count | count := 0. self allBehaviorsDo: [ :each | bar current: (count := count + 1). each selectorsDo: [ :sel | ((each sourceCodeAt: sel) includesSubstring: aString caseSensitive: caseSensitive) ifTrue: [ addMethod value: each value: sel ] ]. (each organization classComment asString includesSubstring: aString caseSensitive: caseSensitive) ifTrue: [ addComment value: each ] ] ] in SystemNavigation>>allMethodsWithSourceString:matchCase: in Block: [ :each | ... [ :aClass | aBlock value: aClass; value: aClass class ] in SystemNavigation>>allBehaviorsDo: in Block: [ :aClass | ... [ :name | aBlock value: (self at: name) ] in SystemDictionary>>allClassesDo: in Block: [ :name | aBlock value: (self at: name) ] OrderedCollection>>do: SystemDictionary>>allClassesDo: SystemNavigation>>allBehaviorsDo: [ :bar | | count | count := 0. self allBehaviorsDo: [ :each | bar current: (count := count + 1). each selectorsDo: [ :sel | ((each sourceCodeAt: sel) includesSubstring: aString caseSensitive: caseSensitive) ifTrue: [ addMethod value: each value: sel ] ]. (each organization classComment asString includesSubstring: aString caseSensitive: caseSensitive) ifTrue: [ addComment value: each ] ] ] in SystemNavigation>>allMethodsWithSourceString:matchCase: in Block: [ :bar | ... BlockClosure>>cull: [ result := block cull: self ] in [ self prepareForRunning. [ result := block cull: self ] on: JobNotification do: [ :notification | notification handle: self ] ] in Job>>run in Block: [ result := block cull: self ] BlockClosure>>on:do: [ self prepareForRunning. [ result := block cull: self ] on: JobNotification do: [ :notification | notification handle: self ] ] in Job>>run in Block: [ ... BlockClosure>>ensure: Job>>run MorphicUIManager(UIManager)>>displayProgress:from:to:during: ByteString(String)>>displayProgressFrom:to:during: SystemNavigation>>allMethodsWithSourceString:matchCase: SystemNavigation>>browseMethodsWithSourceString:matchCase: [ :aPresentation | aPresentation selectLine. self systemNavigation browseMethodsWithSourceString: aPresentation selectedText matchCase: false ] in GLMPharoPlaygroundPresentation(GLMRubricSmalltalkCodePresentation)>>browsingSelectionActions in Block: [ :aPresentation | ... BlockClosure>>glamourValueWithArgs: GLMGenericAction(GLMAction)>>actOn: GLMGenericAction(GLMAction)>>morphicActOn: [ :ann | ann action morphicActOn: aPresentation ] in GLMMorphicPharoPlaygroundRenderer(GLMMorphicWidgetRenderer)>>installActionsOnModel:fromPresentation: in Block: [ :ann | ann action morphicActOn: aPresentation ] BlockClosure>>cull: BlockClosure>>cull:cull:

April 15, 2015

Re: [Pharo-dev] Icon in New list morph.

by Yuriy Tymchuk

Thanks, I forgot about this already because at some point it started to work by itself. I guess the problem was in extent. Uko > On 10 Apr 2015, at 23:28, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-04-02 17:11 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Hi, > > can someone help me to figure out how the icon in a NewList is working? Because when when you add an IconicButton, you have a border showing up on hover and background becoming darker on click. Now when I create a standalone IconicButton I donât get this actionsâ¦ Does anyone have any idea? > > Uko > > > This works for me and it shows the border on hover: > ( IconicButton new > target: Workspace new; > actionSelector: #open; > labelGraphic: (Smalltalk ui icons iconNamed: #workspaceIcon ); > color: Color transparent; > extent: 20 @ 20; > helpText: 'Open Workspace'; > borderWidth: 0) openInHand > > Make sure your button extent is bigger as the icon. > >

April 15, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Yuriy Tymchuk

Can this be because my git name is different from monticello name? Uko > On 09 Apr 2015, at 23:40, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 09/04/2015 23:34, Yuriy Tymchuk a Ã©crit : >> Sad. It happens to me quite a lot. So is this an issue in monticello? > > I don't know. > > Something is happening somewhere with the source code, and as a consequence Monticello test for finding the changes mark everything as changed. > > I'm pushing a solution for that symptom. > > https://pharo.fogbugz.com/default.asp?15321 > > But I haven't found the reason. Something is switching the line endings on some of the MC definitions, and I don't know who or what is doing that (and not everytime). > > Thierry > >> >> >> >>> On 08 Apr 2015, at 22:13, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Uko, >>> >>> you seem to have the same bug Johan is describing. >>> >>> MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff. >>> >>> I've seen it happen at times, but rarely enough so I didn't pay attention to it. >>> >>> Thierry >>> >>> Le 08/04/2015 09:44, Yuriy Tymchuk a Ã©crit : >>>> >>>>> On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>> >>>>> Le 07/04/2015 11:01, Yuriy Tymchuk a Ã©crit : >>>>>> Hi, thank you very much for investigating this. >>>>> >>>>> You're working on it too :) >>>>> >>>>>> These are the steps to reproduce: >>>>>> >>>>>> 1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) >>>>>> 2. Add it as gitfiletree repo to the pharo image. >>>>>> 3. Change something, commit part of the changes with Komitter. >>>>>> 4. Change something more. >>>>>> 5. Open Komitter, you should see a strange diff. >>>>>> 6. Select 1 or 2 methods & commit them. >>>>>> 7. Now you should have only 2 methods in your repo. >>>>> >>>>> I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course). >>>>> >>>>> Can you show a screenshot at step 5? >>>> >>>> Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov >>>> >>>> Uko >>>> >>>>> >>>>> Thierry >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > >

April 15, 2015

Re: [Pharo-dev] Ubuntu ppa - How is it made?

by Norbert Hartl

> Am 15.04.2015 um 13:28 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > Is it built from sources? How does it solve the 32-bit lib problem? Yes it is built from sources. In the older distributions there were explicit 32bit packages, e.g. the infamous ia32-libs. Later they introduced architectures in the mix, so you can add a package:i386 to select the i386 version of it. Taking this it is just a matter of putting the right dependencies in the package file. Norbert

April 15, 2015

Ubuntu ppa - How is it made?

by Sean P. DeNigris

Is it built from sources? How does it solve the 32-bit lib problem? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Ubuntu-ppa-How-is-it-made-tp4819663.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 15, 2015

Re: [Pharo-dev] PetitMarkdown

by Sven Van Caekenberghe

I am sorry, but I don't think you really have looked at this in detail. Read http://en.wikipedia.org/wiki/Markdown History & Extensions, just to known about some of the differences out there. Any language without any formal spec is close to impossible to parse well, it is just hacking. Note that the original MD allows HTML inside ! WTF ? But if it is so easy, please write your own parser. Many have tried, many have failed. Or go read the code of one of them. Here is a cool attempt: http://www.greghendershott.com/2013/11/markdown-parser-redesign.html The fact that github implements their own variant and made it convenient says nothing. For the record, I am using MD myself. > On 14 Apr 2015, at 23:11, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > > On Tue, Apr 14, 2015 at 4:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Furthermore, there is NO MarkDown standard, nor will there ever be. There are slight but annoying differences between the main implementors. > > Not true. There is at least http://spec.commonmark.org/ > > It is super hard to write a parser for MD. > > What do you mean? Why? >

April 14, 2015

Re: [Pharo-dev] PetitMarkdown

by Damien Pollet

On 14 April 2015 at 23:11, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > It is super hard to write a parser for MD. >> > > What do you mean? Why? > The syntax depends on indentation and block layout of text. It's very hard to express using the usual grammar tools. In PetitMarkdown, before Jan added indent-aware parsing to PetitParser, I was thinking of doing multi-pass parsing, first recognizing block-level, then inline syntax. The closest thing to a standard is John Gruber's reference implementation, and that is a sequence of regular expression search-and-replace passes. Not exactly what you'd call a grammar :) Anywayâ¦ https://twitter.com/willmanduffy/status/588057382225346560 -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

April 14, 2015

Re: [Pharo-dev] PetitMarkdown

by kilon alios

Stef gets "fierce emotional" at times, he is very passionate about Pharo. I dont think he has a problem with having a good MD parser though it looks like that will be hard to do because of the nature of the MD syntax but his real problem is people porting doc to MD and abandoning or not even giving Pillar a serious try. That is something that concerns me too. I agree with Stef that Pillar is really nice and frankly MD has little to offer over Pillar. I also dont agree that MD is significantly more readable than Pillar to justify choosing MD over Pillar. Also making a document format tailor made for Pharo needs and ideology comes with its own big benefit that may not be obvious on the short term but long term may make a big difference. I agree also having control over your own format is always a big benefit. Also Pillar is not opposed to MD , quite the contrary it generates MD files as it does HTML , LATEX and PDF files. When I started using Pharo I also did not understand this obsession of remaking so much technology in pharo. But now I know that the moment you integrate something from scratch into a very powerful live environment like Pharo it becomes a completely new thing. It becomes a live thing. Its definitely make the effort well worth it. Now I am also a victim of this "curse" ;) I love Pillar, its super easy to learn, very easy to read and well its made with Pharo which make it also easier to extend. Hands down a winner in my book ;) Go Pillar Go! :) Ps: Help tool already support a very small part of Pillar syntax with its wikisyntax pragma. On Tue, Apr 14, 2015 at 11:03 PM, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > Whoa. > I genuinely don't understand the fierce emotions here. Why do Pillar and > Markdown have to be opposed? Why is wanting support for better parsing of > MD (a commonly used format around the web, and useful in many projects) > somehow an insult to the work done on Pillar? > > (Incidentally, I don't quite understand why Pillar was created in the > first place. Why have a slightly different and incompatible markdown format > from what the rest of the world is using? But that's not the point. We have > both, and it's easy to support both. What's the problem?) > > > On Tue, Apr 14, 2015 at 3:08 PM, stepharo <stepharo(a)free.fr> wrote: > >> I'm really pissed off. Because nearly nobody tried to write anything >> with pillar and you just talk >> about what you do not know. But thanks this is great to see that we are >> spending our energy for people >> who will never even try to use what we are doing. >> Superb! >> >> No need to reply I will not read this thread anymore. And I should not >> even have because it was so obvious. >> >> And yes I 'm REALLY pissed off. You should also say to cyril that what is >> is doing is hopeless because as soon >> as we will have a stupid markdown parser suddenly it will be great. what >> a shit. >> >> So go and write your documentation in any format and do not expect me to >> look at it. >> I'm fed up about people that want doc on the web and when we spend time >> to migrate from latex to >> pillar to generate html and latex do not even consider what we did. >> >> Stef >> >> I would prefer pillar for class / packages comments >>> >> >> I was quite surprised there are any MD defendants considering the >> pillar push. But since diversity is (often) a good think maybe having >> something like gt-inspector there would be cool where you can add this in >> whatever format you want. (And maybe one day someone will write pillar to >> morphic/whatever converter and it would be even cooler.) >> >> It is a difficult topic. I agree with anyone that MarkDown is not a >> good format for parsing. Pillar is the right thing to do here. But there is >> one point of MarkDown that is hard to beat. A MarkDown text is always good >> to read, eben while writing. In something like a class comment it would be >> easy to use. What we don't want is to write system documentation in a >> format that you need to convert first before you can see the result. It is >> either having a wysiwyg editor for those things with pillar below or a >> simple format that can both. >> >> >> my 2 cents, >> >> >> >> thatâs actually my main point too, yes. >> >> Esteban >> >> >> norbert >> >> >> >> >

April 14, 2015

Re: [Pharo-dev] PetitMarkdown

by Dmitri Zagidulin

On Tue, Apr 14, 2015 at 9:21 AM, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: > If there is an interest to use PetitParser/CommonMark in Pharo, I can > spend some time on it. I guess, I would be able to parse majority of the > examples (I am not sure about all the corner cases). > That would be fantastic! In general, even regardless of the use case of using MD for in-Pharo documentation, the ability to parse Markdown is pretty fundamental to a programming language (behind only JSON, XML, and CSV).

April 14, 2015

Re: [Pharo-dev] PetitMarkdown

by Dmitri Zagidulin

On Tue, Apr 14, 2015 at 4:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Furthermore, there is NO MarkDown standard, nor will there ever be. There > are slight but annoying differences between the main implementors. Not true. There is at least http://spec.commonmark.org/ > It is super hard to write a parser for MD. > What do you mean? Why?

April 14, 2015