Pharo-users

By thread

pharo-users@lists.pharo.org

August 2017

84 participants
840 messages

What is proper fix for this? (was: Re: Big Glorp problem w/ type coercion, pls help)

by Herby VojÄÃk

Hello! I think I found the culprit. Few methods posted here: Mapping >> expressionFor: anObject basedOn: anExpression relation: aSymbol "Return our expression using the object's values. e.g. if this was a direct mapping from id->ID and the object had id: 3, then return TABLE.ID=3. Used when rewriting object=object into field=field" | myValue result | myValue := self expressionFor: anObject. result := nil. myValue with: self join allTargetFields do: [:eachValue :eachField | | source | source := anExpression get: self attribute name. source hasDescriptor ifTrue: [source := source getField: eachField]. result := (source get: aSymbol withArguments: (Array with: eachValue)) AND: result]. ^result DirectMapping >> expressionFor: anObject basedOn: anExpression relation: aSymbol "Return our expression using the object's values. e.g. if this was a direct mapping from id->ID and the object had id: 3, then return TABLE.ID=3" | value | value := anObject isNil ifTrue: [nil] ifFalse: [anObject isGlorpExpression ifTrue: [anObject getMapping: self named: self attributeName] ifFalse: [anObject glorpIsCollection ifTrue: [anObject collect: [:each | attribute getValueFrom: each]] ifFalse: [attribute getValueFrom: anObject]]]. ^(anExpression get: self attribute name) get: aSymbol withArguments: (Array with: value) Mapping >> expressionFor: anObject "Return an expression representing the value of the object. This can be nil, an object value or values, an expression, or a collection of expressions (for a composite key, if we're passed an expression)" anObject isNil ifTrue: [^#(nil)]. anObject isGlorpExpression ifFalse: [ ^self mappedFields collect: [:each | self valueOfField: each fromObject: anObject]]. ^self mappedFields collect: [:each | (anObject getField: each)] Mapping >> getValueFrom: anObject ^self attribute getValueFrom: anObject DirectMapping >> valueOfField: aField fromObject: anObject field = aField ifFalse: [self error: 'Mapping doesn''t describe field']. ^self convertedDbValueOf: (self getValueFrom: anObject) DirectMapping >> mappedFields "Return a collection of fields that this mapping will write into any of the containing object's rows" ^Array with: self field The thing is, both Mapping >> expressionFor:basedOn:relation: and the overridden DirectMapping's version eventually send someSource get: aSymbol withArguments: (Array with: eachValue) but in Mapping's code, the value is taken from `myValue := self expressionFor: anObject`. which, as seen in #expressionFor: code, gets the value via self valueOfField: aMappedField fromObject: anObject and indeed, if tried aDirectMapping expressionFor: anObject in debugger, it gets the value of the primary key converted in the below case (that is, as a ByteArray). This is clear from the DirectMapping >> valueOfField:fromObject: code above, which does `self getValueFrom: anObject` (which passes it to `attribute getValueFrom: anObject`) _and_converts_it_. But in the overridden DirectMapping >> expressionFor:basedOn:relation:, the value to be passed in the someSource get: aSymbol withArguments: (Array with: value) is obtained by direct attribute getValueFrom: anObject but _is_not_converted_. IOW, it seems this method was heavily optimized (`attribute getValueFrom:` instead of `self getValueFrom:`, for example), but the conversion, normally present via expressionFor: and ultimately valueOfField:fromObject: was optimized away as well. Now, what is the correct way to fix the method (I hope you agree it is a bug)? This? DirectMapping >> expressionFor: anObject basedOn: anExpression relation: aSymbol "Return our expression using the object's values. e.g. if this was a direct mapping from id->ID and the object had id: 3, then return TABLE.ID=3" | value | value := anObject isNil ifTrue: [nil] ifFalse: [anObject isGlorpExpression ifTrue: [anObject getMapping: self named: self attributeName] ifFalse: [anObject glorpIsCollection ifTrue: [anObject collect: [:each | self valueOfField: aField fromObject: each]] ifFalse: [self valueOfField: aField fromObject: anObject]]]. ^(anExpression get: self attribute name) get: aSymbol withArguments: (Array with: value) or this? DirectMapping >> expressionFor: anObject basedOn: anExpression relation: aSymbol "Return our expression using the object's values. e.g. if this was a direct mapping from id->ID and the object had id: 3, then return TABLE.ID=3" | value | value := anObject isNil ifTrue: [nil] ifFalse: [anObject isGlorpExpression ifTrue: [anObject getMapping: self named: self attributeName] ifFalse: [anObject glorpIsCollection ifTrue: [anObject collect: [:each | self convertedDbValueOf: (attribute getValueFrom: each)]] ifFalse: [self convertedDbValueOf: (attribute getValueFrom: anObject)]]]. ^(anExpression get: self attribute name) get: aSymbol withArguments: (Array with: value) Or something completely different? Thanks, Herby Herby VojÄÃk wrote: > Hello! > > I encountered a problem with OneToOneMapping and type coercion. When > writing data, thing work; when reading data, the right child of relation > fails to convert. > > I tried everything possible to inject converters (even subclassing > GlorpBlobType), but to no avail. RelationExpression passes conversion to > its left child: > > convertedDbValueOf: anObject > "Assume that our types match, so we can ask either child to do the > conversion. That isn't guaranteed, but should at least work for the > common cases." > ^leftChild convertedDbValueOf: anObject. > > but the left child is FieldExpression in case of OneToOneMapping, which: > > convertedDbValueOf: anObject > "We don't do any conversion" > ^anObject > > What is strange, writing works (even the OneToOneMapping, I opened the > sqlite file with an explorer), but second SELECT, one using the relation > (`state := self dao findStateByAgent: agent` in clientSync), fails with > "GlorpDatabaseReadError: Could not coerce arguments". FWIW, the first > one _does_ convert when creating bindings, as it uses MappingExpression > as left child (stepped over it in debugger). > > > > Is it meant to be a strange case that primary key is something > non-primitive needing coercion (in this case, it is a UUID which needs > coercion to ByteArray, even if it is its subclass)? > > > > Here's the stack of running the test which fails: > > PharoDatabaseAccessor(DatabaseAccessor)>>handleError:for: > [ :ex | self handleError: ex for: command ] in [ | result | > self checkPermissionFor: command. > result := [ (self useBinding and: [ command useBinding ]) > ifTrue: [ command executeBoundIn: self ] > ifFalse: [ command executeUnboundIn: self ] ] > on: Dialect error > do: [ :ex | self handleError: ex for: command ]. > aBoolean > ifTrue: [ result ] > ifFalse: [ result upToEnd ] ] in > PharoDatabaseAccessor(DatabaseAccessor)>>executeCommand:returnCursor: > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UDBCSQLite3Library>>apiBindBlob:atColumn:with:with:with: > UDBCSQLite3Library>>with:at:putBlob: > UDBCSQLite3Statement>>at:putByteArray: > UDBCSQLite3ResultSet>>execute:withIndex:withValue: > [ :v | i := self execute: statement withIndex: i withValue: v ] in > UDBCSQLite3ResultSet>>execute:withCollection: > OrderedCollection>>do: > UDBCSQLite3ResultSet>>execute:withCollection: > UDBCSQLite3ResultSet>>execute:with:on: > UDBCSQLite3Connection>>execute:with: > GlorpSQLite3Driver>>basicExecuteSQLString:binding: > PharoDatabaseAccessor>>executeCommandBound: > QuerySelectCommand(DatabaseCommand)>>executeBoundIn: > [ (self useBinding and: [ command useBinding ]) > ifTrue: [ command executeBoundIn: self ] > ifFalse: [ command executeUnboundIn: self ] ] in [ | result | > self checkPermissionFor: command. > result := [ (self useBinding and: [ command useBinding ]) > ifTrue: [ command executeBoundIn: self ] > ifFalse: [ command executeUnboundIn: self ] ] > on: Dialect error > do: [ :ex | self handleError: ex for: command ]. > aBoolean > ifTrue: [ result ] > ifFalse: [ result upToEnd ] ] in > PharoDatabaseAccessor(DatabaseAccessor)>>executeCommand:returnCursor: > BlockClosure>>on:do: > [ | result | > self checkPermissionFor: command. > result := [ (self useBinding and: [ command useBinding ]) > ifTrue: [ command executeBoundIn: self ] > ifFalse: [ command executeUnboundIn: self ] ] > on: Dialect error > do: [ :ex | self handleError: ex for: command ]. > aBoolean > ifTrue: [ result ] > ifFalse: [ result upToEnd ] ] in > PharoDatabaseAccessor(DatabaseAccessor)>>executeCommand:returnCursor: > [ caught := true. > self wait. > blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: > BlockClosure>>ensure: > Semaphore>>critical: > PharoDatabaseAccessor(DatabaseAccessor)>>executeCommand:returnCursor: > [ session accessor executeCommand: command returnCursor: true ] in > SimpleQuery>>rowsFromDatabaseWithParameters: > BlockClosure>>on:do: > SimpleQuery>>rowsFromDatabaseWithParameters: > SimpleQuery(AbstractReadQuery)>>readFromDatabaseWithParameters: > SimpleQuery(AbstractReadQuery)>>executeWithParameters:in: > GlorpSession>>execute: > GlorpSession>>readOneOf:where: > TowergameDao>>findStateByAgent: > [ | agent state | > agent := self dao findAgentById: anObject agentId. > state := self dao findStateByAgent: agent. > ^ NeoJSONObject new > agentId: agent id; > stateVersion: state version; > totalAnsweredQuestions: > (NeoJSONObject new > good: 0; > bad: 0; > yourself); > yourself ] in Towergame>>clientSync: > [ myUnitOfWork := self hasUnitOfWork not. > myUnitOfWork > ifTrue: [ self beginUnitOfWork ]. > result := aBlock numArgs = 1 > ifTrue: [ aBlock value: self ] > ifFalse: [ aBlock value ]. > myUnitOfWork > ifTrue: [ self commitUnitOfWork ] ] in GlorpSession>>inUnitOfWorkDo: > BlockClosure>>ifCurtailed: > GlorpSession>>inUnitOfWorkDo: > TowergameDao>>inUnitOfWorkDo: > Towergame>>clientSync: > TowergameSyncTests>>testPlayerChecksStateVersion > TowergameSyncTests(TestCase)>>performTest > [ self setUp. > self performTest ] in TowergameSyncTests(TestCase)>>runCase > BlockClosure>>ensure: > TowergameSyncTests(TestCase)>>runCase > [ aTestCase runCase ] in [ [ aTestCase runCase ] > on: Halt > do: [ :halt | > "if test was halted we should resume all background failures > to debug all of them together with test process" > failedProcesses keysDo: #resume. > halt pass ] ] in TestExecutionEnvironment>>runTestCaseSafelly: > BlockClosure>>on:do: > [ [ aTestCase runCase ] > on: Halt > do: [ :halt | > "if test was halted we should resume all background failures > to debug all of them together with test process" > failedProcesses keysDo: #resume. > halt pass ] ] in TestExecutionEnvironment>>runTestCaseSafelly: > BlockClosure>>on:do: > TestExecutionEnvironment>>runTestCaseSafelly: > [ self runTestCaseSafelly: aTestCase ] in [ [ self runTestCaseSafelly: > aTestCase ] > ensure: [ testCompleted := true. > watchDogSemaphore signal ]. "signal that test case completes" > self checkForkedProcesses ] in TestExecutionEnvironment>>runTestCase: > BlockClosure>>ensure: > [ [ self runTestCaseSafelly: aTestCase ] > ensure: [ testCompleted := true. > watchDogSemaphore signal ]. "signal that test case completes" > self checkForkedProcesses ] in TestExecutionEnvironment>>runTestCase: > BlockClosure>>ifCurtailed: > TestExecutionEnvironment>>runTestCase: > [ testEnv runTestCase: aTestCase ] in > DefaultExecutionEnvironment>>runTestCase: > [ self value: anExecutionEnvironment. > anExecutionEnvironment activated. > aBlock value ] in CurrentExecutionEnvironment class>>activate:for: > BlockClosure>>ensure: > CurrentExecutionEnvironment class>>activate:for: > TestExecutionEnvironment(ExecutionEnvironment)>>beActiveDuring: > DefaultExecutionEnvironment>>runTestCase: > CurrentExecutionEnvironment class>>runTestCase: > TowergameSyncTests(TestCase)>>runCaseManaged > [ aTestCase announce: TestCaseStarted withResult: self. > aTestCase runCaseManaged. > aTestCase announce: TestCaseEnded withResult: self. > self addPass: aTestCase ] in TestResult>>runCaseForDebug: > BlockClosure>>on:do: > TestResult>>runCaseForDebug: > [ result runCaseForDebug: self ] in TowergameSyncTests(TestCase)>>debug > BlockClosure>>ensure: > TowergameSyncTests(TestCase)>>debug > [ :each | > each debug. > self announceTest: each. > self changed: each ] in [ self tests > do: [ :each | > each debug. > self announceTest: each. > self changed: each ] ] in TestSuite>>debug > OrderedCollection>>do: > [ self tests > do: [ :each | > each debug. > self announceTest: each. > self changed: each ] ] in TestSuite>>debug > BlockClosure>>ensure: > TestSuite>>debug > [ :aSuite | aSuite debug ] in TestRunner>>debugSuite: > BlockClosure>>cull: > BlockClosure>>cull:cull: > [ aBlock cull: aTestSuite cull: result ] in TestRunner>>executeSuite:as: > BlockClosure>>ensure: > TestRunner>>executeSuite:as: > TestRunner>>debugSuite: > TestRunner>>debug: > TestRunner>>errorSelected: > PluggableListMorph>>changeModelSelection: > PluggableListMorph>>mouseUpOnSingle: > PluggableListMorph>>mouseUp: > PluggableListMorph(Morph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > PluggableListMorph(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>handleMouseUp: > MouseButtonEvent>>sentTo: > [ ^ anEvent sentTo: self ] in MorphicEventDispatcher>>dispatchEvent:with: > BlockClosure>>ensure: > MorphicEventDispatcher>>dispatchEvent:with: > PluggableListMorph(Morph)>>processEvent:using: > PluggableListMorph(Morph)>>processEvent: > PluggableListMorph>>handleFocusEvent: > [ ActiveHand := self. > ActiveEvent := anEvent. > result := focusHolder > handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: > self)) ] in HandMorph>>sendFocusEvent:to:clear: > BlockClosure>>on:do: > WorldMorph(PasteUpMorph)>>becomeActiveDuring: > HandMorph>>sendFocusEvent:to:clear: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendMouseEvent: > HandMorph>>handleEvent: > HandMorph>>processEventsFromQueue: > HandMorph>>processEvents > [ :h | > self activeHand: h. > h processEvents. > self activeHand: nil ] in WorldState>>doOneCycleNowFor: > Array(SequenceableCollection)>>do: > WorldState>>handsDo: > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > [ [ WorldMorph doOneCycle. > Processor yield. > false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess > > > > And here's the code: > > > Towergame.st: > > GlorpBlobType subclass: #GlorpBlob2Type > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > > !GlorpBlob2Type methodsFor: 'types' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > converterForStType: aClass > aClass = UUID ifTrue: [ ^ UuidConverter new ]. > ^ super converterForStType: aClass! ! > > > Object subclass: #TgAct > instanceVariableNames: 'agent tool timestamp' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > !TgAct commentStamp: 'HerbyVojcik 8/5/2017 19:23' prior: 0! > I represent a relationship between a player (TgAgent) > and a device (TgTool). > > In particular, I am created whenever a player logs in to the game from > different device > than it was last time (or first time, ever).! > > > !TgAct methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > agent > ^ agent! ! > > !TgAct methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > agent: anObject > agent := anObject! ! > > !TgAct methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > timestamp: anObject > timestamp := anObject! ! > > !TgAct methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > tool > ^ tool! ! > > !TgAct methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > tool: anObject > tool := anObject! ! > > !TgAct methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > timestamp > ^ timestamp! ! > > > !TgAct methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > initialize > > super initialize. > > agent := nil. > timestamp := DateAndTime now asUTC. > tool := nil.! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TgAct class > instanceVariableNames: ''! > > !TgAct class methodsFor: 'instance creation' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > agent: aTgAgent tool: aTgTool > ^ self new > agent: aTgAgent; > tool: aTgTool; > yourself! ! > > > Object subclass: #TgAgent > instanceVariableNames: 'id' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > !TgAgent commentStamp: 'HerbyVojcik 8/5/2017 19:22' prior: 0! > I represent a towergame player. > > I only contain player-related information; > the game state itself is in TgState.! > > > !TgAgent methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > initialize > > super initialize. > > id := nil.! ! > > > !TgAgent methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > id: anObject > id := anObject! ! > > !TgAgent methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > id > ^ id! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TgAgent class > instanceVariableNames: ''! > > !TgAgent class methodsFor: 'instance creation' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > id: aString > ^ self new > id: aString; > yourself! ! > > > Object subclass: #TgAnswers > instanceVariableNames: 'good bad' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > !TgAnswers commentStamp: 'HerbyVojcik 8/5/2017 20:23' prior: 0! > I represent the answered question stats. > > I know how many good / bad answered questions there is.! > > > !TgAnswers methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > good > ^ good! ! > > !TgAnswers methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > bad: anObject > bad := anObject! ! > > !TgAnswers methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > bad > ^ bad! ! > > !TgAnswers methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > good: anObject > good := anObject! ! > > > !TgAnswers methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > initialize > > super initialize. > > bad := 0. > good := 0.! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TgAnswers class > instanceVariableNames: ''! > > !TgAnswers class methodsFor: 'instance creation' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > good: anInteger bad: anInteger2 > ^ self new > good: anInteger; > bad: anInteger2; > yourself! ! > > > Object subclass: #TgFloors > instanceVariableNames: 'total reinforced' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > !TgFloors commentStamp: 'HerbyVojcik 8/5/2017 20:22' prior: 0! > I represent the floor building status. > > I know how many floors are build and how many of them is reinforced.! > > > !TgFloors methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > total > ^ total! ! > > !TgFloors methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > total: anObject > total := anObject! ! > > !TgFloors methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > reinforced > ^ reinforced! ! > > !TgFloors methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > reinforced: anObject > reinforced := anObject! ! > > > !TgFloors methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > initialize > > super initialize. > > reinforced := 0. > total := 0.! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TgFloors class > instanceVariableNames: ''! > > !TgFloors class methodsFor: 'instance creation' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > total: anInteger > ^ self total: anInteger reinforced: 0! ! > > !TgFloors class methodsFor: 'instance creation' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > total: anInteger reinforced: anInteger2 > ^ self new > total: anInteger; > reinforced: anInteger2; > yourself! ! > > > Object subclass: #TgState > instanceVariableNames: 'agent version packs valuables score bestScore > answers' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > !TgState commentStamp: 'HerbyVojcik 8/5/2017 20:20' prior: 0! > I represent the game state. > > I have relation to a player (TgAgent) and have a version. > Then, I contain (directly or indirectly) other parts that > make up the player's game state. > > Whenever I am changed by game progress, my version is changed as well.! > > > !TgState methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > initialize > > super initialize. > > agent := nil. > answers := nil. > bestScore := nil. > packs := Set new. > score := nil. > valuables := nil. > version := nil.! ! > > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > score: anObject > score := anObject! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > bestScore: anObject > bestScore := anObject! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > agent: anObject > agent := anObject! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > score > ^ score! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > packs > ^ packs! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > version > ^ version! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > bestScore > ^ bestScore! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > agent > ^ agent! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > answers: anObject > answers := anObject! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > valuables: anObject > valuables := anObject! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > valuables > ^ valuables! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > version: anObject > version := anObject! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > answers > ^ answers! ! > > !TgState methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > packs: anObject > packs := anObject! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TgState class > instanceVariableNames: ''! > > !TgState class methodsFor: 'instance creation' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > agent: aTgAgent version: aString > ^ self new > agent: aTgAgent; > version: aString; > yourself! ! > > > Object subclass: #TgTool > instanceVariableNames: 'id' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > !TgTool commentStamp: 'HerbyVojcik 8/5/2017 19:26' prior: 0! > I represent the device (mobile phone, web browser, ..) > that player uses to connect to game.! > > > !TgTool methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > initialize > > super initialize. > > id := nil.! ! > > > !TgTool methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > id: anObject > id := anObject! ! > > !TgTool methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > id > ^ id! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TgTool class > instanceVariableNames: ''! > > !TgTool class methodsFor: 'instance creation' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > id: aString > ^ self new > id: aString; > yourself! ! > > > Object subclass: #TgValuables > instanceVariableNames: 'coins gems' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > !TgValuables commentStamp: 'HerbyVojcik 8/5/2017 20:22' prior: 0! > I represent a purse. > > I know how many coins and gems there is.! > > > !TgValuables methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > initialize > > super initialize. > > coins := 0. > gems := 0.! ! > > > !TgValuables methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > gems: anObject > gems := anObject! ! > > !TgValuables methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > coins: anObject > coins := anObject! ! > > !TgValuables methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > gems > ^ gems! ! > > !TgValuables methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > coins > ^ coins! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TgValuables class > instanceVariableNames: ''! > > !TgValuables class methodsFor: 'instance creation' stamp: > 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > coins: anInteger gems: anInteger2 > ^ self new > coins: anInteger; > gems: anInteger2; > yourself! ! > > > Object subclass: #Towergame > instanceVariableNames: 'dao' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > !Towergame commentStamp: 'HerbyVojcik 5/17/2017 17:19' prior: 0! > I am the Towergame app class. > > I configure and start towergame server processing.! > > > !Towergame methodsFor: 'actions' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > clientSync: anObject > self dao inUnitOfWorkDo: [ > | agent state | > agent := self dao findAgentById: anObject agentId. > state := self dao findStateByAgent: agent. > ^ NeoJSONObject new > agentId: agent id; > stateVersion: state version; > totalAnsweredQuestions: (NeoJSONObject new good: 0; bad: 0; yourself); > yourself ]! ! > > > !Towergame methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > initialize > > super initialize. > > dao := nil. > ! ! > > > !Towergame methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > dao: anObject > dao := anObject! ! > > !Towergame methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > dao > ^ dao! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > Towergame class > instanceVariableNames: 'default'! > > !Towergame class methodsFor: 'instance creation' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > dao: aDao > ^ self new > dao: aDao; > yourself! ! > > > !Towergame class methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > defaultDbLogin > | databaseFile | > databaseFile := Smalltalk imageDirectory asFileReference / 'towergame.db'. > ^ Login new > database: UDBCSQLite3Platform new; > host: ''; > port: ''; > username: ''; > password: ''; > databaseName: databaseFile fullPath asZnUrl asString; > yourself ! ! > > !Towergame class methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > default > ^ default ifNil: [ default := self > dao: (self daoForLogin: self defaultDbLogin) > ]! ! > > !Towergame class methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > defaultPort > ^ 4998! ! > > > !Towergame class methodsFor: 'configuration' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > configureServer > (self serverFor: self default on: self defaultPort) start; register > ! ! > > !Towergame class methodsFor: 'configuration' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > configureSqlite3 > > PharoDatabaseAccessor DefaultDriver: GlorpSQLite3Driver! ! > > !Towergame class methodsFor: 'configuration' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > configure > self configureSqlite3. > self configureServer.! ! > > > !Towergame class methodsFor: 'factory' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > daoForLogin: aLogin > ^ TowergameDao forLogin: aLogin! ! > > !Towergame class methodsFor: 'factory' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > serverFor: aTowergame on: port > ^ (ZnServer on: port) > delegate: (TowergameDelegate on: aTowergame); > yourself! ! > > > Object subclass: #TowergameDao > instanceVariableNames: 'glorpSession glorpLogin' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > > !TowergameDao methodsFor: 'transactions' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > inUnitOfWorkDo: aBlock > ^ self glorpSession inUnitOfWorkDo: aBlock! ! > > > !TowergameDao methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > initialize > > super initialize. > > glorpLogin := nil. > glorpSession := nil.! ! > > > !TowergameDao methodsFor: 'initialize-release' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > reset > glorpSession := nil.! ! > > > !TowergameDao methodsFor: 'query' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > findStateByAgent: anAgent > ^ self glorpSession readOneOf: TgState where: [ :one | one agent = > anAgent ]! ! > > !TowergameDao methodsFor: 'query' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > findAgentById: anUUID > ^ self glorpSession readOneOf: TgAgent where: [ :one | one id = anUUID ]! ! > > > !TowergameDao methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > glorpLogin: anObject > glorpLogin := anObject! ! > > !TowergameDao methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > glorpLogin > ^ glorpLogin! ! > > !TowergameDao methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > glorpSession > glorpSession ifNil: [ > glorpSession := TowergameDescriptorSystem sessionForLogin: self > glorpLogin ]. > glorpSession accessor isLoggedIn ifFalse: [ > glorpSession accessor login ]. > ^ glorpSession! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TowergameDao class > instanceVariableNames: ''! > > !TowergameDao class methodsFor: 'instance creation' stamp: > 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > forLogin: aLogin > ^ self new > glorpLogin: aLogin; > yourself! ! > > > ZnDispatcherDelegate subclass: #TowergameDelegate > instanceVariableNames: 'towergame' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > > !TowergameDelegate methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > towergame > ^ towergame! ! > > !TowergameDelegate methodsFor: 'accessing' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > towergame: anObject > towergame := anObject! ! > > > !TowergameDelegate methodsFor: 'initialization' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > initialize > super initialize. > towergame := nil. > self > map: '/api/v1/sync' > to: [ :request :response | self syncRequest: request toResponse: > response ]! ! > > > !TowergameDelegate methodsFor: 'action' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > syncRequest: request toResponse: response > | requestPayload responsePayload uuidKeys | > uuidKeys := #(agentId stateVersion deviceId). > request method == #POST ifFalse: [ ^ ZnResponse methodNotAllowed: > request ]. > requestPayload := NeoJSONObject fromString: request contents. > requestPayload ifNotNil: [ > uuidKeys do: [ :each | requestPayload at: each ifPresentPut: [ :s | UUID > fromString: s ] ] ]. > responsePayload := self towergame clientSync: requestPayload. > responsePayload ifNotNil: [ > uuidKeys do: [ :each | responsePayload at: each ifPresentPut: #asString > ] ]. > ^ response > entity: (ZnEntity > with: (NeoJSONWriter toString: responsePayload) > type: ZnMimeType applicationJson); > yourself! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > TowergameDelegate class > instanceVariableNames: ''! > > !TowergameDelegate class methodsFor: 'instance creation' stamp: > 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > on: aTowergame > ^ self new towergame: aTowergame; yourself! ! > > > DescriptorSystem subclass: #TowergameDescriptorSystem > instanceVariableNames: 'uuidConverter' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > tableForAGENT: aTable > > (aTable createFieldNamed: 'id' type: platform blob2) bePrimaryKey. > ! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > classModelForTgAgent: aClassModel > aClassModel > newAttributeNamed: #id type: UUID! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbyVojcik > 8/14/2017 18:24'! > tableForSTATE: aTable > > (aTable createFieldNamed: 'agent' type: platform blob2) in: [ :agentField | > agentField bePrimaryKey. > aTable addForeignKeyFrom: agentField to: ((self tableNamed: 'AGENT') > fieldNamed: 'id') ]. > (aTable createFieldNamed: 'version' type: platform blob) beIndexed. > ! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > descriptorForTgAgent: aDescriptor > | table | > table := self tableNamed: 'AGENT'. > aDescriptor table: table. > (aDescriptor newMapping: DirectMapping) > from: #id to: (table fieldNamed: 'id').! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > tableForACT: aTable > > (aTable createFieldNamed: 'agent' type: platform blob2) beIndexed. > (aTable createFieldNamed: 'tool' type: platform blob2) beIndexed. > (aTable createFieldNamed: 'timestamp' type: platform timestamp) beIndexed. > ! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > descriptorForTgState: aDescriptor > | table | > table := self tableNamed: 'STATE'. > aDescriptor table: table. > (aDescriptor newMapping: OneToOneMapping) attributeName: #agent. > (aDescriptor newMapping: DirectMapping) > from: #version to: (table fieldNamed: 'version').! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > converterBetweenStType: aClass andField: aField > (aClass = UUID and: [ aField impliedSmalltalkType = ByteArray]) > ifTrue: [ ^ self uuidConverter ]. > ^ super converterBetweenStType: aClass andField: aField! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > classModelForTgState: aClassModel > "agent version packs valuables score bestScore answers" > aClassModel > newAttributeNamed: #agent type: TgAgent; > newAttributeNamed: #version type: UUID! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > classModelForTgTool: aClassModel > aClassModel > newAttributeNamed: #id > ! ! > > !TowergameDescriptorSystem methodsFor: 'glorp' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > classModelForTgAct: aClassModel > aClassModel > newAttributeNamed: #timestamp; > newAttributeNamed: #agent type: TgAgent; > newAttributeNamed: #tool type: TgTool! ! > > > !TowergameDescriptorSystem methodsFor: 'accessing' stamp: > 'HerbertVojÃÂÃÂk 8/14/2017 18:09:53'! > uuidConverter > ^ uuidConverter ifNil: [ uuidConverter := UuidConverter new name: > 'uuid'; yourself ]! ! > > > DatabaseConverter subclass: #UuidConverter > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame'! > > !UuidConverter methodsFor: 'converting' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > convert: anObject toDatabaseRepresentationAs: aDatabaseType > ^ anObject ifNotNil: [ ByteArray withAll: anObject ]! ! > > !UuidConverter methodsFor: 'converting' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > convert: anObject fromDatabaseRepresentationAs: aDatabaseType > ^ anObject ifNotNil: [ UUID withAll: anObject ]! ! > 'From Pharo6.0 of 13 May 2016 [Latest update: #60510] on 14 August 2017 > at 6:26:30.67905 pm'! > > !DatabasePlatform methodsFor: '*Towergame' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > blob2 > ^self typeNamed: #blob ifAbsentPut: [GlorpBlob2Type new].! ! > 'From Pharo6.0 of 13 May 2016 [Latest update: #60510] on 14 August 2017 > at 6:26:30.68005 pm'! > > !Dictionary methodsFor: '*Towergame' stamp: 'HerbertVojÃÂÃÂk 8/14/2017 > 18:09:53'! > at: key ifPresentPut: aBlock > "Lookup the given key in the receiver. If it is present, update it > with the value of evaluating the given block with the value associated > with the key. Otherwise, answer nil." > > ^ self at: key ifPresent: [ :value | self at: key put: (aBlock cull: > value) ]! ! > > > > > TowergameTests.st: > > TestCase subclass: #TowergameServerTests > instanceVariableNames: 'randomPort towergame server' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame-Tests'! > > !TowergameServerTests methodsFor: 'running' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > uidy: aString > ^ UUID fromString36: aString ! ! > > !TowergameServerTests methodsFor: 'running' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > setUp > randomPort := 1700 + 32 atRandom. > towergame := Mock new. > server := Towergame serverFor: towergame on: randomPort. > server start. > self > assert: server isRunning & server isListening > description: ('Failed to start server on port {1}. Is there one > already?' format: { server port }) > ! ! > > !TowergameServerTests methodsFor: 'running' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > tearDown > server stop! ! > > > !TowergameServerTests methodsFor: 'tests' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > testEmptySyncRequest > | znClient response | > (towergame stub clientSync: Arg payload) willReturn: nil. > znClient := self znClientForSync: 'null'. > response := znClient timeout: 1; post; response. > response should satisfy: #isSuccess. > response contentType should equal: ZnMimeType applicationJson. > (STON fromString: response entity contents) should equal: nil. > Arg payload should equal: nil! ! > > !TowergameServerTests methodsFor: 'tests' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > testRejectEmptyGetSyncRequest > | znClient response | > (towergame stub clientSync: Arg payload) willReturn: nil. > znClient := self znClientForSync: 'null'. > response := znClient timeout: 1; get; response. > response code should equal: ZnStatusLine methodNotAllowed code. > towergame should not receive clientSync: Any! ! > > !TowergameServerTests methodsFor: 'tests' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > testNonEmptySyncRequest > | znClient response | > (towergame stub clientSync: Arg payload) willReturn: { #agentId -> (self > uidy: '007') } asDictionary. > znClient := self znClientForSync: > ('\{"deviceId":"{1}","agentAnsweredQuestions":\{"good":1,"bad":2\}\}' > format: { self uidy: 'Q' }). > response := znClient timeout: 1; post; response. > response should satisfy: #isSuccess. > response contentType should equal: ZnMimeType applicationJson. > (STON fromString: response entity contents) should equal: { 'agentId' -> > (self uidy: '007') asString } asDictionary. > Arg payload in: [ :arg | > arg deviceId should equal: (self uidy: 'Q'). > arg agentAnsweredQuestions should satisfy: #notNil. > arg agentAnsweredQuestions good should equal: 1. > arg agentAnsweredQuestions bad should equal: 2 ] > ! ! > > > !TowergameServerTests methodsFor: 'private' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > znClientForSync: jsonString > ^ ZnClient new > url: server localUrl; > path: '/api/v1/sync'; > entity: > (ZnEntity > with: jsonString > type: ZnMimeType applicationJson) > ! ! > > > TestCase subclass: #TowergameSyncTests > instanceVariableNames: 'towergame session dao' > classVariableNames: '' > poolDictionaries: '' > category: 'Towergame-Tests'! > > !TowergameSyncTests methodsFor: 'tests' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > testPlayerChecksStateVersionAndIsBehind > | result payload | > session createTables. > session inUnitOfWorkDo: [ > | agent state | > agent := TgAgent id: (self uidy: '007'). > state := (TgState agent: agent version: (self uidy: '18-eff')) > packs: #('foopack' 'barpack') asSet; > valuables: (TgValuables coins: 20 gems: 3); > score: (TgFloors total: 4 reinforced: 1); > bestScore: (TgFloors total: 18); > answers: (TgAnswers good: 2 bad: 3); > yourself. > session registerAll: {state. TgAct agent: agent tool: (TgTool id: (self > uidy: 'Q7') ) } ]. > towergame := Towergame dao: dao. > payload := NeoJSONObject new > agentId: (self uidy: '007'); stateVersion: (self uidy: '23-fefe'); > deviceId: (self uidy: 'Q7'). > result := towergame clientSync: payload. > result where agentId should equal: (self uidy: '007'). > result where stateVersion should equal: (self uidy: '18-eff'). > result where purchasedPacks should satisfy: [ :x | x asSet should equal: > #('foopack' 'barpack') asSet ]. > result where valuables coins should equal: 20. > result where valuables gems should equal: 3. > result where floorsNumber current should equal: 4. > result where floorsNumber best should equal: 18. > result where floorsNumber reinforced should equal: 1. > result where agentAnsweredQuestions good should equal: 2. > result where agentAnsweredQuestions bad should equal: 3. > result where totalAnsweredQuestions good should equal: 2. > result where totalAnsweredQuestions bad should equal: 3! ! > > !TowergameSyncTests methodsFor: 'tests' stamp: 'HerbyVojcik 8/14/2017 > 18:18'! > testPlayerChecksStateVersion > | result payload | > session createTables. > session inUnitOfWorkDo: [ > | agent state | > agent := TgAgent id: (self uidy: '007'). > state := TgState agent: agent version: (self uidy: '23-fefe'). > session registerAll: {state. TgAct agent: agent tool: (TgTool id: (self > uidy: 'Q7') ) } ]. > towergame := Towergame dao: dao. > payload := NeoJSONObject new > agentId: (self uidy: '007'); stateVersion: (self uidy: '23-fefe'); > deviceId: (self uidy: 'Q7'). > result := towergame clientSync: payload. > result where agentId should equal: (self uidy: '007'). > result where stateVersion should equal: (self uidy: '23-fefe'). > result where totalAnsweredQuestions good should equal: 0. > result where totalAnsweredQuestions bad should equal: 0! ! > > > !TowergameSyncTests methodsFor: 'running' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > uidy: aString > ^ UUID fromString36: aString ! ! > > !TowergameSyncTests methodsFor: 'running' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > setUp > dao := Towergame daoForLogin: self loginToTemporaryDatabase. > session := dao glorpSession. > ! ! > > !TowergameSyncTests methodsFor: 'running' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > tearDown > session logout! ! > > !TowergameSyncTests methodsFor: 'running' stamp: 'HerbyVojcik 8/14/2017 > 18:16'! > loginToTemporaryDatabase > ^ Login new > database: UDBCSQLite3Platform new; > host: ''; > port: ''; > username: ''; > password: ''; > databaseName: ''; > yourself! ! > > > > > > BaselineOfTowergame.st: > BaselineOf subclass: #BaselineOfTowergame > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'BaselineOfTowergame'! > > !BaselineOfTowergame methodsFor: 'baseline' stamp: 'HerbertVojÃÂÃÂk > 8/14/2017 18:09:53'! > baseline: spec > <baseline> > spec for: #common do: [ spec > > package: 'Towergame' with: [ spec > requires: #('GlorpSQLite' 'NeoJSON') ]; > package: 'Towergame-Tests' with: [ spec > requires: #('Towergame' 'Mocketry') ]; > > configuration: 'GlorpSQLite' with: [ spec > version: #stable; > repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ]; > configuration: 'NeoJSON' with: [ spec > version: #stable; > repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ]; > baseline: 'Mocketry' with: [ spec > repository: 'github://dionisiydk/Mocketry:v4.0.x' ]; > > group: 'default' with: #('Core'); > group: 'development' with: #('Core' 'Tests'); > group: 'Core' with: #('Towergame'); > group: 'Tests' with: #('Towergame-Tests') ] > ! ! > > >

Aug. 15, 2017

Re: [Pharo-users] [Pharo-dev] including Pillar in Pharo image by default

by Cyril Ferlicot

On mar. 15 aoÃ»t 2017 at 12:02, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > P.S. 3 And I realize that there is an pillar issue > > "Create a small parser independant of PetitParser for a light pillar" > > https://github.com/pillar-markup/pillar/issues/174 > > AFAIK this parser already exists. The hand written parser from in the > Pier CMS. Some small adaptations are probably necessary. > > Hi! Yes, this parser exists. When I created PetitPillar I extracted it into its own package to not lose the code. So it is in the Pillar repository even if it is not loaded by default. In this issue I wanted to bring only a subset of this parser for Pharo and add what might be missing. But since people want to create a subset of PetitParser this issue becomes obsolete. > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 15, 2017

Re: [Pharo-users] [Pharo-dev] including Pillar in Pharo image by default

by H. Hirzel

P.S. 3 And I realize that there is an pillar issue "Create a small parser independant of PetitParser for a light pillar" https://github.com/pillar-markup/pillar/issues/174 AFAIK this parser already exists. The hand written parser from in the Pier CMS. Some small adaptations are probably necessary. On 8/15/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > P.S. 2 > > And yes the Pillar syntax which goes back to the Pier syntax [1] has > been around for quite some time > > > 2008 at least according to > > Pier > http://wiki.squeak.org/squeak/3700 > > http://www.piercms.com/doc/syntax > > > > [1] Pharo 6.1 catalog entry for Pillar > > Pillar is a wiki-like syntax, its document model, a parser for it, and > a set of exporters (e.g., HTML, LaTeX, Markdown...). Pillar is > primarily used as the wiki syntax behind the *Pier > CMS>http://piercms.com*. Pillar is also being used to write books: > e.g., *the Enterprise Pharo book>http://books.pharo.org/*. > > The original creator of Pillar (formerly known as ''the syntax behind > the Pier CMS'') is Lukas Renggli. Nevertheless, *Damien > Cassou>damien.cassou(a)inria.fr* is now the maintainer. The website is > at *http://www.smalltalkhub.com/#!/~Pier/Pillar*. Issues should be > reported to *https://github.com/pillar-markup/pillar/issues* > > On 8/15/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> P.S. +1 for including pillar in the 6.2 image , then start working on >> the document tree and see how it can be adapted. >> >> On 8/15/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> Offray, >>> >>> thanks for the nice write-up about the general usefulness of Markdown >>> for writing papers. >>> >>> Stephen D. wrote yesterday in a terse way >>> >>> "We can change the syntax or propose an alternate one as soon as it >>> uses the same internal structure. >>> >>> Stef" >>> >>> This means that Pillars tagging system may be changed to a more >>> generally known tagging system later. >>> >>> I assume with 'internal structure' he refers to the AST/Document >>> Object Model of Pillar which would need to be aligned with one of >>> another markup system. >>> >>> Maybe the gap is not all that large. >>> >>> Personally I think as well that if Pharo could also be used as a >>> markdown (commonmark) editor with its tool-chain to generate different >>> types of documents would expand the area of application considerably. >>> >>> --Hannes >>> >>> >>> On 8/15/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> >>> wrote: >>>> Hi, >>>> >>>> While I appreciate the historical perspective, I continue to be with >>>> Tim >>>> on this (and I consider myself part of the Pharo Community). I have >>>> also >>>> personal preferences for other light markup languages (like txt2tags[1] >>>> and dokuwiki's[2]), but I will stick with Pandoc's Markdown, because is >>>> support everything Stephan or any professional author wants to do and >>>> in >>>> fact you can create full books with it, including references, tables, >>>> images, and bibliographic references (which are not supported by Pillar >>>> AFAIK), but also because is an emerging standard beyond the programmers >>>> community, including academicians and researchers with the Scholarly >>>> Markdown[3] initiative and with possibilities to import and export >>>> from/to several markup languages[4]. >>>> >>>> [1] http://txt2tags.org/ >>>> [2] https://www.dokuwiki.org/wiki:syntax >>>> [3] http://scholmd.org/ >>>> [4] http://pandoc.org/ >>>> >>>> I don't share the vision of particular communities choosing particular >>>> markup languages as default, because, if you already payed the price of >>>> learning that particular language/environment, you are willing to pay >>>> the price with whatever that community choose in other fronts like DVCS >>>> or markup languages. Python community supports reST, but also markdown >>>> and several other markup languages and Jupyter notebooks[5] user >>>> Markdown by default. In fact, the Iceberg Git support shows the >>>> increasing concern to bridge the Pharo world with the stuff you already >>>> know and I think that a similar approach should be taken in the >>>> documentation/markup front, even if this implies breaking compatibility >>>> with the canonical Smalltalk way (TM) (I really like that critical >>>> approach from Pharo to the past). >>>> >>>> [5] http://jupyter.org/ >>>> >>>> That being said, I don't think that should be exclusively one way or >>>> another. We can have Pillar and (Pandoc's) Markdown, if the community >>>> doesn't reach and agreement on only one. >>>> >>>> I plan to explore the Brick editor once I have time and will try to add >>>> Pandoc's Markdown support. Unfortunately, in the past I have not had >>>> many luck testing and giving feedback on Moose alpha releases of tools >>>> and my questions/comments on them remain largely unanswered or simply >>>> ignored for long time (or just forever), so my priority on testing >>>> these >>>> tools have just decreased, but once Brick editor become more well >>>> supported, Pandoc's Markdown support for it will be in my target and >>>> concerns. >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> On 14/08/17 12:48, Jimmie Houchin wrote: >>>>> >>>>> Thank Tim, >>>>> >>>>> My primary reason to submit the message was not to necessarily >>>>> persuade you per se. But to provide something historical for the >>>>> mailing list as this can be a recurring subject. Why use Pillar markup >>>>> instead of ???(insert personal favorite). >>>>> >>>>> If Pharo were to decide on a different markup language. The question >>>>> would still be which one, why and then how do we proceed. Then our >>>>> extensions may not be accepted by the greater body of users of said >>>>> markup. We would still be contributing to the fragmentation of markup. >>>>> As far as familiarity, I don't know. And familiarity with what. I do >>>>> not find that reStructuredText to be similar to Markdown. >>>>> >>>>> It would stop people from asking why we aren't using Markdown. But it >>>>> wouldn't prevent others. Why aren't we using GFM Markdown, or Kramdown >>>>> or Commonmark or ...? Why aren't we using YAML or reST or AsciiDoc or >>>>> insert latest greatest creation markup or current flavor of the >>>>> moment. Which is why I wanted to point out that there is no consensus >>>>> among users of markup languages. At least I do not see one. Nor do I >>>>> believe that we have seen the end of creation of new markup languages. >>>>> >>>>> I understand the difficulty, though I do not suffer from it as I have >>>>> not mastered any of those other languages. I have been using >>>>> Squeak/Pharo for a long time. I struggle when I look at those other >>>>> languages. To me they are the foreign ones. >>>>> >>>>> And I do not see these emerging standards you refer to. When we see >>>>> Python, Ruby, Perl, C++, various projects, etc. communities having >>>>> consensus on a common markup for documentation. Then I see an emerging >>>>> standard. Until then it seems to possibly be an emerging standard for >>>>> a particular markup language which is among the set of markup >>>>> languages. >>>>> >>>>> If we were the only language and development environment doing our own >>>>> thing. Then we might have a very good reason to talk. But we are not. >>>>> Python with its enormous community does its own thing. I don't know >>>>> that other languages have a consensus for markup for documentation >>>>> except for Python and Pharo. >>>>> >>>>> While writing this email I went and discovered that even GitHub is not >>>>> dogmatic about the subject. Obviously they have an opinion. But they >>>>> permit multiple markup languages. Quite possibly someone could write a >>>>> Pillar tool for GitHub to use and then we could just submit >>>>> Readme.pillar for our projects. :) >>>>> >>>>> https://github.com/github/markup >>>>> >>>>> Shows that GitHub allows for .markdown, .mdown, .mkdn, .md; .textile; >>>>> .rdoc; .org; .creole; .mediawiki, .wiki; .rst; .asciidoc, .adoc, .asc; >>>>> .pod. So it seems that there are many communities on GitHub who >>>>> prefer their own markup and tools. >>>>> >>>>> We could possibly write the Pillar tool for GitHub or an exporter to >>>>> the preferred markup language of the above. >>>>> >>>>> This author provides arguments for using reStructuredText over >>>>> Markdown for GitHub documents. Citing deficiencies in Markdown and >>>>> expressiveness in reST. >>>>> >>>>> https://gist.github.com/dupuy/1855764 >>>>> >>>>> So again. I am just not seeing a consensus around any emerging >>>>> standard for "the markup language". >>>>> >>>>> At the same time if you are desirous of writing in Commonmark in your >>>>> text editor. Can you not write conversion software that goes from >>>>> Commonmark to Pillar? Thus, meeting want you want and what we require? >>>>> If you were to do so, you would definitely have a good understanding >>>>> of the differences in philosophy and capabilities of each. Just a >>>>> thought. >>>>> >>>>> Any way, thanks for engaging in the conversation. I wasn't targeting >>>>> you personally, but rather the topic. You are not alone in your >>>>> thinking. The Pharo community is not alone in its thinking either. >>>>> >>>>> Thanks. >>>>> >>>>> Jimmie >>>>> >>>>> >>>>> >>>>> >>>>> On 08/14/2017 11:34 AM, Tim Mackinnon wrote: >>>>>> Jimmie et al. nicely reasoned arguments - and Doru's point about >>>>>> controlling the syntax is an interesting one that I hadnât thought >>>>>> about. >>>>>> >>>>>> Personally, I find having too many similar syntaxâs confusing - >>>>>> contributing to things is hard enough - having to remember that its >>>>>> !! Instead of ## and ââ instead of ** is just frustrating for me. >>>>>> >>>>>> My vote would be what Peter suggested - use >>>>>> http://spec.commonmark.org/0.28/ and put our Pillar extensions back >>>>>> on top for things that Stef was mentioning. (I think thatâs what Iâve >>>>>> understood gfm markdown is). >>>>>> >>>>>> Sure, maybe we were first with Pillar, but for me, lots of >>>>>> programming is in other languages, and I use Smalltalk where I can, >>>>>> and a hybrid of multiple languages and projects is often the reality >>>>>> - so a lowest common denominator of Markdown is just easier. The fact >>>>>> that we are quite close to what our colleagues in other languages use >>>>>> (regardless of what Python has chosen), is quite interesting. >>>>>> >>>>>> That said, if the community wants to stick to its gunâs thats fine - >>>>>> I will probably still investigate how to use Commonmark for myself, >>>>>> and will still contribute to Pillar docs where I can (and curse >>>>>> history) - but I think we are long better off trying to join emerging >>>>>> standards where we can particularly if they arenât our core language >>>>>> thing. And it just makes it less frictionless for ourselves and >>>>>> newcomers. >>>>>> >>>>>> Of course, if we were to move, we would need to translate a lot of >>>>>> quality docs to a new format - but I would be up for contributing to >>>>>> that if that was a deciding factor. >>>>>> >>>>>> Tim >>>>>> >>>>>> >>>>>>> On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com >>>>>>> <mailto:jlhouchin@gmail.com>> wrote: >>>>>>> >>>>>>> TL;DR >>>>>>> >>>>>>> Main points: >>>>>>> Their is no universally accepted markup language. >>>>>>> Other communities use their own markup and tools and their markup >>>>>>> and tools choice is not determine by other communities decisions. >>>>>>> We need a language and tool chain that we can control and maintain >>>>>>> which accomplishes our goals. >>>>>>> Our language and tools already exist and have existed for longer >>>>>>> than most of the other markup languages. Of course they existed in >>>>>>> various different forms over the years and have evolved into what >>>>>>> they currently are. >>>>>>> It might be nice to have a GFM Markdown exporter from Pillar for >>>>>>> GitHub projects. >>>>>>> >>>>>>> >>>>>>> I just want to comment on the fact that there is no universal markup >>>>>>> language that every development community has settled upon. Making >>>>>>> Markdown or some variant the markup language for Pharo only aligns >>>>>>> us with a certain part of the development community. Even Markdown >>>>>>> is not unified as is evident by the discussion. >>>>>>> >>>>>>> It is true that GitHub uses their variant of Markdown. And as long >>>>>>> as we use GitHub we will need to use their variant for documents >>>>>>> that reside on their system. >>>>>>> >>>>>>> However as a significant counter example to lets all use gfm >>>>>>> Markdown, is the Python community and their documentation. >>>>>>> >>>>>>> https://docs.python.org/devguide/documenting.html >>>>>>> """ >>>>>>> 7. Documenting Python >>>>>>> The Python language has a substantial body of documentation, much of >>>>>>> it contributed by various authors. The markup used for the Python >>>>>>> documentation is reStructuredText, developed by the docutils >>>>>>> project, amended by custom directives and using a toolset named >>>>>>> Sphinx to post-process the HTML output. >>>>>>> >>>>>>> This document describes the style guide for our documentation as >>>>>>> well as the custom reStructuredText markup introduced by Sphinx to >>>>>>> support Python documentation and how it should be used. >>>>>>> >>>>>>> The documentation in HTML, PDF or EPUB format is generated from text >>>>>>> files written using the reStructuredText format and contained in the >>>>>>> CPython Git repository. >>>>>>> """ >>>>>>> >>>>>>> So the Python community uses their own markup language and their own >>>>>>> tool chain. So therefore, it is not wrong for a community to go >>>>>>> their own way, for their own reasons. Even within the conventional >>>>>>> file based languages such as Python. >>>>>>> >>>>>>> The fact that you have tools such as Pandoc, suggest that there is >>>>>>> not true uniformity or unanimity among developers as to the best >>>>>>> markup language or tool chain. >>>>>>> >>>>>>> I believe that a language that we can control and maintain is better >>>>>>> than adopting some other foreign markup language that is neither >>>>>>> better, nor unanimously used by all. That would ultimately >>>>>>> potentially require extensions to accomplish our goals. Then we >>>>>>> would be maintaining someone else's language with our extensions >>>>>>> that may or may not be accepted by the larger community. This does >>>>>>> not prevent but rather encourages fragmentation of the existing >>>>>>> Markdown. >>>>>>> >>>>>>> Regardless, Pillar markup already exists. The tools in Pharo already >>>>>>> understand it. Should someone desire to use Pharo which is far more >>>>>>> different from Python/Ruby/etc. than Pillar syntax is from Markdown. >>>>>>> Then it should be worth their effort to learn our tools. >>>>>>> >>>>>>> Pillar markup is older than Markdown, etc. It's history begins in >>>>>>> SmallWiki. It isn't as if we jumped up and decided to create >>>>>>> something new in order to be different. Our markup and tools are >>>>>>> older. They (and others) are the ones that decided to do their own >>>>>>> markup and tools. And it is okay that they did so. Nothing wrong >>>>>>> with doing so. Every community has the right to what they believe is >>>>>>> best for their community. Even if other communities disagree. >>>>>>> >>>>>>> The ability to control and maintain is highly valuable. We can >>>>>>> understand what our requirements are for today. But we can not know >>>>>>> what the requirements are in the future. Nor can we know that >>>>>>> Markdown or whomever will have such requirements when they appear. >>>>>>> It is easy to see in the beginning with the Squeak Wiki syntax to >>>>>>> the now Pillar syntax, changes that have been made to accommodate >>>>>>> new requirements as they became known. We need to maintain that >>>>>>> ability. Sure we would reserve the right to do so in any language we >>>>>>> adopt. But the then current standard bearer of said language would >>>>>>> determine whether what we do is acceptable and incorporate or >>>>>>> whether we are then in fact adding to their fragmentation. Pillar is >>>>>>> ours. There is not fragmentation when we evolve. >>>>>>> >>>>>>> However, since we have made a decision to use GitHub and GitHub has >>>>>>> made a decision to use their own GFM Markdown. It might be nice to >>>>>>> have a GFM Markdown exporter from Pillar for GitHub projects. This >>>>>>> way we can use our own tools and markup language to accomplish >>>>>>> whatever we want to accomplish. Including generating a Readme.md for >>>>>>> our GitHub projects. >>>>>>> >>>>>>> Just wanted to toss out this simple opinion and facts about the >>>>>>> situation. >>>>>>> >>>>>>> Jimmie >>>>>>> >>>>>>> >>>>>>> On 08/14/2017 04:10 AM, Tudor Girba wrote: >>>>>>>> Hi Tim, >>>>>>>> >>>>>>>> The main benefit of relying on Pillar is that we control its syntax >>>>>>>> and can easily extend it for our purposes. Also, there was quite a >>>>>>>> bit of engineering invested in it, and even though we still need to >>>>>>>> improve it, there exists a pipeline that allows people to quickly >>>>>>>> publish books. >>>>>>>> >>>>>>>> The figure embedding problem is one example of the need to >>>>>>>> customize the syntax and behavior, but this extensibility will >>>>>>>> become even more important for supporting the idea of moving the >>>>>>>> documentation inside the image. For example, the ability to refer >>>>>>>> to a class, method or other artifacts will be quite relevant soon >>>>>>>> especially that the editor will be able to embed advanced elements >>>>>>>> inside the text. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Stef - I think yourâs is a fair requirement (in fact I hit >>>>>>>>> something similar when doing a static website using a JS markdown >>>>>>>>> framework - and this is why I mentioned Kramdown which adds a few >>>>>>>>> extras to regular markdown - but it feels like it goes a bit too >>>>>>>>> far). >>>>>>>>> >>>>>>>>> My next item on my learning todo list was to try and replace that >>>>>>>>> JS generator with something from Smalltalk - so I think we can >>>>>>>>> possibly come up with something that ticks all the right boxes >>>>>>>>> (Iâd like to try anyway). >>>>>>>>> >>>>>>>>> Iâll keep working away on it and compare notes with you. I think >>>>>>>>> with Pillar, it was more that things like headers, bold and >>>>>>>>> italics are similar concepts but just use different characters - >>>>>>>>> so I keep typing the wrong thing and getting frustrated >>>>>>>>> particularly when we embrace Git and readme.md is in markdown. >>>>>>>>> >>>>>>>>> >>>>>>>>> Tim >>>>>>>>> >>>>>>>>>> On 13 Aug 2017, at 20:08, Stephane Ducasse >>>>>>>>>> <stepharo.self(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi tim >>>>>>>>>> >>>>>>>>>> I personally do not care much about the syntax but I care about >>>>>>>>>> what I >>>>>>>>>> can do with it >>>>>>>>>> (ref, cite, ... ) >>>>>>>>>> I cannot write books in markdown because reference to >>>>>>>>>> figures!!!!!! >>>>>>>>>> were missing. >>>>>>>>>> >>>>>>>>>> And of course a parser because markdown is not really nice to >>>>>>>>>> parse >>>>>>>>>> and I will not write a parser because I have something else to >>>>>>>>>> do. >>>>>>>>>> I >>>>>>>>>> want to make pillar smaller, simpler, nicer. >>>>>>>>>> >>>>>>>>>> Now if someone come up with a parser that parse for REAL a >>>>>>>>>> markdown >>>>>>>>>> that can be extended with decent behavior (figure reference, >>>>>>>>>> section >>>>>>>>>> reference, cite) and can be extended because there are many >>>>>>>>>> things >>>>>>>>>> that can be nice to have (for example I want to be able to write >>>>>>>>>> the >>>>>>>>>> example below) and emit a PillarModel (AST) we can talk to have >>>>>>>>>> another syntax for Pillar but not before. >>>>>>>>>> >>>>>>>>>> [[[test >>>>>>>>>> 2+3 >>>>>>>>>>>>> 5 >>>>>>>>>> ]]] >>>>>>>>>> >>>>>>>>>> and being able to verify that the doc is in sync. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon >>>>>>>>>> <tim(a)testit.works> wrote: >>>>>>>>>>> Of course, I/we recognise and appreciate all the work that's >>>>>>>>>>> gone into docs in pillar - but I think it should be reasonably >>>>>>>>>>> straightforward to write a converter as it is pretty closely >>>>>>>>>>> related from what I have seen. >>>>>>>>>>> >>>>>>>>>>> So I don't make the suggestion flippantly, and would want to >>>>>>>>>>> help write a converter and get us to a common ground where we >>>>>>>>>>> can differentiate on the aspects where we can excel. >>>>>>>>>>> >>>>>>>>>>> Tim >>>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> A long time issue with Markdown was that there was no >>>>>>>>>>>> standardization (and when I used Pillar's MD export ~2 years >>>>>>>>>>>> ago it didn't work well). >>>>>>>>>>>> >>>>>>>>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has >>>>>>>>>>>> become the de-facto standard, so it would make sense to support >>>>>>>>>>>> it bidirectionally with Pillar. >>>>>>>>>>>> >>>>>>>>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>>>>>>>> Well, technically it is just a CommonMark, as I am not using >>>>>>>>>>>> any github extensions. >>>>>>>>>>>> (Github uses CommonMarks and adds just couple small >>>>>>>>>>>> extensions.) >>>>>>>>>>>> >>>>>>>>>>>> Peter >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> www.feenk.com >>>>>>>> >>>>>>>> âLive like you mean it." >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >

Aug. 15, 2017

Re: [Pharo-users] [Pharo-dev] including Pillar in Pharo image by default

by H. Hirzel

P.S. 2 And yes the Pillar syntax which goes back to the Pier syntax [1] has been around for quite some time 2008 at least according to Pier http://wiki.squeak.org/squeak/3700 http://www.piercms.com/doc/syntax [1] Pharo 6.1 catalog entry for Pillar Pillar is a wiki-like syntax, its document model, a parser for it, and a set of exporters (e.g., HTML, LaTeX, Markdown...). Pillar is primarily used as the wiki syntax behind the *Pier CMS>http://piercms.com*. Pillar is also being used to write books: e.g., *the Enterprise Pharo book>http://books.pharo.org/*. The original creator of Pillar (formerly known as ''the syntax behind the Pier CMS'') is Lukas Renggli. Nevertheless, *Damien Cassou>damien.cassou(a)inria.fr* is now the maintainer. The website is at *http://www.smalltalkhub.com/#!/~Pier/Pillar*. Issues should be reported to *https://github.com/pillar-markup/pillar/issues* On 8/15/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > P.S. +1 for including pillar in the 6.2 image , then start working on > the document tree and see how it can be adapted. > > On 8/15/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> Offray, >> >> thanks for the nice write-up about the general usefulness of Markdown >> for writing papers. >> >> Stephen D. wrote yesterday in a terse way >> >> "We can change the syntax or propose an alternate one as soon as it >> uses the same internal structure. >> >> Stef" >> >> This means that Pillars tagging system may be changed to a more >> generally known tagging system later. >> >> I assume with 'internal structure' he refers to the AST/Document >> Object Model of Pillar which would need to be aligned with one of >> another markup system. >> >> Maybe the gap is not all that large. >> >> Personally I think as well that if Pharo could also be used as a >> markdown (commonmark) editor with its tool-chain to generate different >> types of documents would expand the area of application considerably. >> >> --Hannes >> >> >> On 8/15/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> >> wrote: >>> Hi, >>> >>> While I appreciate the historical perspective, I continue to be with Tim >>> on this (and I consider myself part of the Pharo Community). I have also >>> personal preferences for other light markup languages (like txt2tags[1] >>> and dokuwiki's[2]), but I will stick with Pandoc's Markdown, because is >>> support everything Stephan or any professional author wants to do and in >>> fact you can create full books with it, including references, tables, >>> images, and bibliographic references (which are not supported by Pillar >>> AFAIK), but also because is an emerging standard beyond the programmers >>> community, including academicians and researchers with the Scholarly >>> Markdown[3] initiative and with possibilities to import and export >>> from/to several markup languages[4]. >>> >>> [1] http://txt2tags.org/ >>> [2] https://www.dokuwiki.org/wiki:syntax >>> [3] http://scholmd.org/ >>> [4] http://pandoc.org/ >>> >>> I don't share the vision of particular communities choosing particular >>> markup languages as default, because, if you already payed the price of >>> learning that particular language/environment, you are willing to pay >>> the price with whatever that community choose in other fronts like DVCS >>> or markup languages. Python community supports reST, but also markdown >>> and several other markup languages and Jupyter notebooks[5] user >>> Markdown by default. In fact, the Iceberg Git support shows the >>> increasing concern to bridge the Pharo world with the stuff you already >>> know and I think that a similar approach should be taken in the >>> documentation/markup front, even if this implies breaking compatibility >>> with the canonical Smalltalk way (TM) (I really like that critical >>> approach from Pharo to the past). >>> >>> [5] http://jupyter.org/ >>> >>> That being said, I don't think that should be exclusively one way or >>> another. We can have Pillar and (Pandoc's) Markdown, if the community >>> doesn't reach and agreement on only one. >>> >>> I plan to explore the Brick editor once I have time and will try to add >>> Pandoc's Markdown support. Unfortunately, in the past I have not had >>> many luck testing and giving feedback on Moose alpha releases of tools >>> and my questions/comments on them remain largely unanswered or simply >>> ignored for long time (or just forever), so my priority on testing these >>> tools have just decreased, but once Brick editor become more well >>> supported, Pandoc's Markdown support for it will be in my target and >>> concerns. >>> >>> Cheers, >>> >>> Offray >>> >>> On 14/08/17 12:48, Jimmie Houchin wrote: >>>> >>>> Thank Tim, >>>> >>>> My primary reason to submit the message was not to necessarily >>>> persuade you per se. But to provide something historical for the >>>> mailing list as this can be a recurring subject. Why use Pillar markup >>>> instead of ???(insert personal favorite). >>>> >>>> If Pharo were to decide on a different markup language. The question >>>> would still be which one, why and then how do we proceed. Then our >>>> extensions may not be accepted by the greater body of users of said >>>> markup. We would still be contributing to the fragmentation of markup. >>>> As far as familiarity, I don't know. And familiarity with what. I do >>>> not find that reStructuredText to be similar to Markdown. >>>> >>>> It would stop people from asking why we aren't using Markdown. But it >>>> wouldn't prevent others. Why aren't we using GFM Markdown, or Kramdown >>>> or Commonmark or ...? Why aren't we using YAML or reST or AsciiDoc or >>>> insert latest greatest creation markup or current flavor of the >>>> moment. Which is why I wanted to point out that there is no consensus >>>> among users of markup languages. At least I do not see one. Nor do I >>>> believe that we have seen the end of creation of new markup languages. >>>> >>>> I understand the difficulty, though I do not suffer from it as I have >>>> not mastered any of those other languages. I have been using >>>> Squeak/Pharo for a long time. I struggle when I look at those other >>>> languages. To me they are the foreign ones. >>>> >>>> And I do not see these emerging standards you refer to. When we see >>>> Python, Ruby, Perl, C++, various projects, etc. communities having >>>> consensus on a common markup for documentation. Then I see an emerging >>>> standard. Until then it seems to possibly be an emerging standard for >>>> a particular markup language which is among the set of markup >>>> languages. >>>> >>>> If we were the only language and development environment doing our own >>>> thing. Then we might have a very good reason to talk. But we are not. >>>> Python with its enormous community does its own thing. I don't know >>>> that other languages have a consensus for markup for documentation >>>> except for Python and Pharo. >>>> >>>> While writing this email I went and discovered that even GitHub is not >>>> dogmatic about the subject. Obviously they have an opinion. But they >>>> permit multiple markup languages. Quite possibly someone could write a >>>> Pillar tool for GitHub to use and then we could just submit >>>> Readme.pillar for our projects. :) >>>> >>>> https://github.com/github/markup >>>> >>>> Shows that GitHub allows for .markdown, .mdown, .mkdn, .md; .textile; >>>> .rdoc; .org; .creole; .mediawiki, .wiki; .rst; .asciidoc, .adoc, .asc; >>>> .pod. So it seems that there are many communities on GitHub who >>>> prefer their own markup and tools. >>>> >>>> We could possibly write the Pillar tool for GitHub or an exporter to >>>> the preferred markup language of the above. >>>> >>>> This author provides arguments for using reStructuredText over >>>> Markdown for GitHub documents. Citing deficiencies in Markdown and >>>> expressiveness in reST. >>>> >>>> https://gist.github.com/dupuy/1855764 >>>> >>>> So again. I am just not seeing a consensus around any emerging >>>> standard for "the markup language". >>>> >>>> At the same time if you are desirous of writing in Commonmark in your >>>> text editor. Can you not write conversion software that goes from >>>> Commonmark to Pillar? Thus, meeting want you want and what we require? >>>> If you were to do so, you would definitely have a good understanding >>>> of the differences in philosophy and capabilities of each. Just a >>>> thought. >>>> >>>> Any way, thanks for engaging in the conversation. I wasn't targeting >>>> you personally, but rather the topic. You are not alone in your >>>> thinking. The Pharo community is not alone in its thinking either. >>>> >>>> Thanks. >>>> >>>> Jimmie >>>> >>>> >>>> >>>> >>>> On 08/14/2017 11:34 AM, Tim Mackinnon wrote: >>>>> Jimmie et al. nicely reasoned arguments - and Doru's point about >>>>> controlling the syntax is an interesting one that I hadnât thought >>>>> about. >>>>> >>>>> Personally, I find having too many similar syntaxâs confusing - >>>>> contributing to things is hard enough - having to remember that its >>>>> !! Instead of ## and ââ instead of ** is just frustrating for me. >>>>> >>>>> My vote would be what Peter suggested - use >>>>> http://spec.commonmark.org/0.28/ and put our Pillar extensions back >>>>> on top for things that Stef was mentioning. (I think thatâs what Iâve >>>>> understood gfm markdown is). >>>>> >>>>> Sure, maybe we were first with Pillar, but for me, lots of >>>>> programming is in other languages, and I use Smalltalk where I can, >>>>> and a hybrid of multiple languages and projects is often the reality >>>>> - so a lowest common denominator of Markdown is just easier. The fact >>>>> that we are quite close to what our colleagues in other languages use >>>>> (regardless of what Python has chosen), is quite interesting. >>>>> >>>>> That said, if the community wants to stick to its gunâs thats fine - >>>>> I will probably still investigate how to use Commonmark for myself, >>>>> and will still contribute to Pillar docs where I can (and curse >>>>> history) - but I think we are long better off trying to join emerging >>>>> standards where we can particularly if they arenât our core language >>>>> thing. And it just makes it less frictionless for ourselves and >>>>> newcomers. >>>>> >>>>> Of course, if we were to move, we would need to translate a lot of >>>>> quality docs to a new format - but I would be up for contributing to >>>>> that if that was a deciding factor. >>>>> >>>>> Tim >>>>> >>>>> >>>>>> On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com >>>>>> <mailto:jlhouchin@gmail.com>> wrote: >>>>>> >>>>>> TL;DR >>>>>> >>>>>> Main points: >>>>>> Their is no universally accepted markup language. >>>>>> Other communities use their own markup and tools and their markup >>>>>> and tools choice is not determine by other communities decisions. >>>>>> We need a language and tool chain that we can control and maintain >>>>>> which accomplishes our goals. >>>>>> Our language and tools already exist and have existed for longer >>>>>> than most of the other markup languages. Of course they existed in >>>>>> various different forms over the years and have evolved into what >>>>>> they currently are. >>>>>> It might be nice to have a GFM Markdown exporter from Pillar for >>>>>> GitHub projects. >>>>>> >>>>>> >>>>>> I just want to comment on the fact that there is no universal markup >>>>>> language that every development community has settled upon. Making >>>>>> Markdown or some variant the markup language for Pharo only aligns >>>>>> us with a certain part of the development community. Even Markdown >>>>>> is not unified as is evident by the discussion. >>>>>> >>>>>> It is true that GitHub uses their variant of Markdown. And as long >>>>>> as we use GitHub we will need to use their variant for documents >>>>>> that reside on their system. >>>>>> >>>>>> However as a significant counter example to lets all use gfm >>>>>> Markdown, is the Python community and their documentation. >>>>>> >>>>>> https://docs.python.org/devguide/documenting.html >>>>>> """ >>>>>> 7. Documenting Python >>>>>> The Python language has a substantial body of documentation, much of >>>>>> it contributed by various authors. The markup used for the Python >>>>>> documentation is reStructuredText, developed by the docutils >>>>>> project, amended by custom directives and using a toolset named >>>>>> Sphinx to post-process the HTML output. >>>>>> >>>>>> This document describes the style guide for our documentation as >>>>>> well as the custom reStructuredText markup introduced by Sphinx to >>>>>> support Python documentation and how it should be used. >>>>>> >>>>>> The documentation in HTML, PDF or EPUB format is generated from text >>>>>> files written using the reStructuredText format and contained in the >>>>>> CPython Git repository. >>>>>> """ >>>>>> >>>>>> So the Python community uses their own markup language and their own >>>>>> tool chain. So therefore, it is not wrong for a community to go >>>>>> their own way, for their own reasons. Even within the conventional >>>>>> file based languages such as Python. >>>>>> >>>>>> The fact that you have tools such as Pandoc, suggest that there is >>>>>> not true uniformity or unanimity among developers as to the best >>>>>> markup language or tool chain. >>>>>> >>>>>> I believe that a language that we can control and maintain is better >>>>>> than adopting some other foreign markup language that is neither >>>>>> better, nor unanimously used by all. That would ultimately >>>>>> potentially require extensions to accomplish our goals. Then we >>>>>> would be maintaining someone else's language with our extensions >>>>>> that may or may not be accepted by the larger community. This does >>>>>> not prevent but rather encourages fragmentation of the existing >>>>>> Markdown. >>>>>> >>>>>> Regardless, Pillar markup already exists. The tools in Pharo already >>>>>> understand it. Should someone desire to use Pharo which is far more >>>>>> different from Python/Ruby/etc. than Pillar syntax is from Markdown. >>>>>> Then it should be worth their effort to learn our tools. >>>>>> >>>>>> Pillar markup is older than Markdown, etc. It's history begins in >>>>>> SmallWiki. It isn't as if we jumped up and decided to create >>>>>> something new in order to be different. Our markup and tools are >>>>>> older. They (and others) are the ones that decided to do their own >>>>>> markup and tools. And it is okay that they did so. Nothing wrong >>>>>> with doing so. Every community has the right to what they believe is >>>>>> best for their community. Even if other communities disagree. >>>>>> >>>>>> The ability to control and maintain is highly valuable. We can >>>>>> understand what our requirements are for today. But we can not know >>>>>> what the requirements are in the future. Nor can we know that >>>>>> Markdown or whomever will have such requirements when they appear. >>>>>> It is easy to see in the beginning with the Squeak Wiki syntax to >>>>>> the now Pillar syntax, changes that have been made to accommodate >>>>>> new requirements as they became known. We need to maintain that >>>>>> ability. Sure we would reserve the right to do so in any language we >>>>>> adopt. But the then current standard bearer of said language would >>>>>> determine whether what we do is acceptable and incorporate or >>>>>> whether we are then in fact adding to their fragmentation. Pillar is >>>>>> ours. There is not fragmentation when we evolve. >>>>>> >>>>>> However, since we have made a decision to use GitHub and GitHub has >>>>>> made a decision to use their own GFM Markdown. It might be nice to >>>>>> have a GFM Markdown exporter from Pillar for GitHub projects. This >>>>>> way we can use our own tools and markup language to accomplish >>>>>> whatever we want to accomplish. Including generating a Readme.md for >>>>>> our GitHub projects. >>>>>> >>>>>> Just wanted to toss out this simple opinion and facts about the >>>>>> situation. >>>>>> >>>>>> Jimmie >>>>>> >>>>>> >>>>>> On 08/14/2017 04:10 AM, Tudor Girba wrote: >>>>>>> Hi Tim, >>>>>>> >>>>>>> The main benefit of relying on Pillar is that we control its syntax >>>>>>> and can easily extend it for our purposes. Also, there was quite a >>>>>>> bit of engineering invested in it, and even though we still need to >>>>>>> improve it, there exists a pipeline that allows people to quickly >>>>>>> publish books. >>>>>>> >>>>>>> The figure embedding problem is one example of the need to >>>>>>> customize the syntax and behavior, but this extensibility will >>>>>>> become even more important for supporting the idea of moving the >>>>>>> documentation inside the image. For example, the ability to refer >>>>>>> to a class, method or other artifacts will be quite relevant soon >>>>>>> especially that the editor will be able to embed advanced elements >>>>>>> inside the text. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Stef - I think yourâs is a fair requirement (in fact I hit >>>>>>>> something similar when doing a static website using a JS markdown >>>>>>>> framework - and this is why I mentioned Kramdown which adds a few >>>>>>>> extras to regular markdown - but it feels like it goes a bit too >>>>>>>> far). >>>>>>>> >>>>>>>> My next item on my learning todo list was to try and replace that >>>>>>>> JS generator with something from Smalltalk - so I think we can >>>>>>>> possibly come up with something that ticks all the right boxes >>>>>>>> (Iâd like to try anyway). >>>>>>>> >>>>>>>> Iâll keep working away on it and compare notes with you. I think >>>>>>>> with Pillar, it was more that things like headers, bold and >>>>>>>> italics are similar concepts but just use different characters - >>>>>>>> so I keep typing the wrong thing and getting frustrated >>>>>>>> particularly when we embrace Git and readme.md is in markdown. >>>>>>>> >>>>>>>> >>>>>>>> Tim >>>>>>>> >>>>>>>>> On 13 Aug 2017, at 20:08, Stephane Ducasse >>>>>>>>> <stepharo.self(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi tim >>>>>>>>> >>>>>>>>> I personally do not care much about the syntax but I care about >>>>>>>>> what I >>>>>>>>> can do with it >>>>>>>>> (ref, cite, ... ) >>>>>>>>> I cannot write books in markdown because reference to >>>>>>>>> figures!!!!!! >>>>>>>>> were missing. >>>>>>>>> >>>>>>>>> And of course a parser because markdown is not really nice to >>>>>>>>> parse >>>>>>>>> and I will not write a parser because I have something else to do. >>>>>>>>> I >>>>>>>>> want to make pillar smaller, simpler, nicer. >>>>>>>>> >>>>>>>>> Now if someone come up with a parser that parse for REAL a >>>>>>>>> markdown >>>>>>>>> that can be extended with decent behavior (figure reference, >>>>>>>>> section >>>>>>>>> reference, cite) and can be extended because there are many things >>>>>>>>> that can be nice to have (for example I want to be able to write >>>>>>>>> the >>>>>>>>> example below) and emit a PillarModel (AST) we can talk to have >>>>>>>>> another syntax for Pillar but not before. >>>>>>>>> >>>>>>>>> [[[test >>>>>>>>> 2+3 >>>>>>>>>>>> 5 >>>>>>>>> ]]] >>>>>>>>> >>>>>>>>> and being able to verify that the doc is in sync. >>>>>>>>> >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon >>>>>>>>> <tim(a)testit.works> wrote: >>>>>>>>>> Of course, I/we recognise and appreciate all the work that's >>>>>>>>>> gone into docs in pillar - but I think it should be reasonably >>>>>>>>>> straightforward to write a converter as it is pretty closely >>>>>>>>>> related from what I have seen. >>>>>>>>>> >>>>>>>>>> So I don't make the suggestion flippantly, and would want to >>>>>>>>>> help write a converter and get us to a common ground where we >>>>>>>>>> can differentiate on the aspects where we can excel. >>>>>>>>>> >>>>>>>>>> Tim >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> A long time issue with Markdown was that there was no >>>>>>>>>>> standardization (and when I used Pillar's MD export ~2 years >>>>>>>>>>> ago it didn't work well). >>>>>>>>>>> >>>>>>>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has >>>>>>>>>>> become the de-facto standard, so it would make sense to support >>>>>>>>>>> it bidirectionally with Pillar. >>>>>>>>>>> >>>>>>>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>>>>>>> Well, technically it is just a CommonMark, as I am not using >>>>>>>>>>> any github extensions. >>>>>>>>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>>>>>>>> >>>>>>>>>>> Peter >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.feenk.com >>>>>>> >>>>>>> âLive like you mean it." >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >

Aug. 15, 2017

Re: [Pharo-users] [Pharo-dev] including Pillar in Pharo image by default

by H. Hirzel

P.S. +1 for including pillar in the 6.2 image , then start working on the document tree and see how it can be adapted. On 8/15/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Offray, > > thanks for the nice write-up about the general usefulness of Markdown > for writing papers. > > Stephen D. wrote yesterday in a terse way > > "We can change the syntax or propose an alternate one as soon as it > uses the same internal structure. > > Stef" > > This means that Pillars tagging system may be changed to a more > generally known tagging system later. > > I assume with 'internal structure' he refers to the AST/Document > Object Model of Pillar which would need to be aligned with one of > another markup system. > > Maybe the gap is not all that large. > > Personally I think as well that if Pharo could also be used as a > markdown (commonmark) editor with its tool-chain to generate different > types of documents would expand the area of application considerably. > > --Hannes > > > On 8/15/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> Hi, >> >> While I appreciate the historical perspective, I continue to be with Tim >> on this (and I consider myself part of the Pharo Community). I have also >> personal preferences for other light markup languages (like txt2tags[1] >> and dokuwiki's[2]), but I will stick with Pandoc's Markdown, because is >> support everything Stephan or any professional author wants to do and in >> fact you can create full books with it, including references, tables, >> images, and bibliographic references (which are not supported by Pillar >> AFAIK), but also because is an emerging standard beyond the programmers >> community, including academicians and researchers with the Scholarly >> Markdown[3] initiative and with possibilities to import and export >> from/to several markup languages[4]. >> >> [1] http://txt2tags.org/ >> [2] https://www.dokuwiki.org/wiki:syntax >> [3] http://scholmd.org/ >> [4] http://pandoc.org/ >> >> I don't share the vision of particular communities choosing particular >> markup languages as default, because, if you already payed the price of >> learning that particular language/environment, you are willing to pay >> the price with whatever that community choose in other fronts like DVCS >> or markup languages. Python community supports reST, but also markdown >> and several other markup languages and Jupyter notebooks[5] user >> Markdown by default. In fact, the Iceberg Git support shows the >> increasing concern to bridge the Pharo world with the stuff you already >> know and I think that a similar approach should be taken in the >> documentation/markup front, even if this implies breaking compatibility >> with the canonical Smalltalk way (TM) (I really like that critical >> approach from Pharo to the past). >> >> [5] http://jupyter.org/ >> >> That being said, I don't think that should be exclusively one way or >> another. We can have Pillar and (Pandoc's) Markdown, if the community >> doesn't reach and agreement on only one. >> >> I plan to explore the Brick editor once I have time and will try to add >> Pandoc's Markdown support. Unfortunately, in the past I have not had >> many luck testing and giving feedback on Moose alpha releases of tools >> and my questions/comments on them remain largely unanswered or simply >> ignored for long time (or just forever), so my priority on testing these >> tools have just decreased, but once Brick editor become more well >> supported, Pandoc's Markdown support for it will be in my target and >> concerns. >> >> Cheers, >> >> Offray >> >> On 14/08/17 12:48, Jimmie Houchin wrote: >>> >>> Thank Tim, >>> >>> My primary reason to submit the message was not to necessarily >>> persuade you per se. But to provide something historical for the >>> mailing list as this can be a recurring subject. Why use Pillar markup >>> instead of ???(insert personal favorite). >>> >>> If Pharo were to decide on a different markup language. The question >>> would still be which one, why and then how do we proceed. Then our >>> extensions may not be accepted by the greater body of users of said >>> markup. We would still be contributing to the fragmentation of markup. >>> As far as familiarity, I don't know. And familiarity with what. I do >>> not find that reStructuredText to be similar to Markdown. >>> >>> It would stop people from asking why we aren't using Markdown. But it >>> wouldn't prevent others. Why aren't we using GFM Markdown, or Kramdown >>> or Commonmark or ...? Why aren't we using YAML or reST or AsciiDoc or >>> insert latest greatest creation markup or current flavor of the >>> moment. Which is why I wanted to point out that there is no consensus >>> among users of markup languages. At least I do not see one. Nor do I >>> believe that we have seen the end of creation of new markup languages. >>> >>> I understand the difficulty, though I do not suffer from it as I have >>> not mastered any of those other languages. I have been using >>> Squeak/Pharo for a long time. I struggle when I look at those other >>> languages. To me they are the foreign ones. >>> >>> And I do not see these emerging standards you refer to. When we see >>> Python, Ruby, Perl, C++, various projects, etc. communities having >>> consensus on a common markup for documentation. Then I see an emerging >>> standard. Until then it seems to possibly be an emerging standard for >>> a particular markup language which is among the set of markup languages. >>> >>> If we were the only language and development environment doing our own >>> thing. Then we might have a very good reason to talk. But we are not. >>> Python with its enormous community does its own thing. I don't know >>> that other languages have a consensus for markup for documentation >>> except for Python and Pharo. >>> >>> While writing this email I went and discovered that even GitHub is not >>> dogmatic about the subject. Obviously they have an opinion. But they >>> permit multiple markup languages. Quite possibly someone could write a >>> Pillar tool for GitHub to use and then we could just submit >>> Readme.pillar for our projects. :) >>> >>> https://github.com/github/markup >>> >>> Shows that GitHub allows for .markdown, .mdown, .mkdn, .md; .textile; >>> .rdoc; .org; .creole; .mediawiki, .wiki; .rst; .asciidoc, .adoc, .asc; >>> .pod. So it seems that there are many communities on GitHub who >>> prefer their own markup and tools. >>> >>> We could possibly write the Pillar tool for GitHub or an exporter to >>> the preferred markup language of the above. >>> >>> This author provides arguments for using reStructuredText over >>> Markdown for GitHub documents. Citing deficiencies in Markdown and >>> expressiveness in reST. >>> >>> https://gist.github.com/dupuy/1855764 >>> >>> So again. I am just not seeing a consensus around any emerging >>> standard for "the markup language". >>> >>> At the same time if you are desirous of writing in Commonmark in your >>> text editor. Can you not write conversion software that goes from >>> Commonmark to Pillar? Thus, meeting want you want and what we require? >>> If you were to do so, you would definitely have a good understanding >>> of the differences in philosophy and capabilities of each. Just a >>> thought. >>> >>> Any way, thanks for engaging in the conversation. I wasn't targeting >>> you personally, but rather the topic. You are not alone in your >>> thinking. The Pharo community is not alone in its thinking either. >>> >>> Thanks. >>> >>> Jimmie >>> >>> >>> >>> >>> On 08/14/2017 11:34 AM, Tim Mackinnon wrote: >>>> Jimmie et al. nicely reasoned arguments - and Doru's point about >>>> controlling the syntax is an interesting one that I hadnât thought >>>> about. >>>> >>>> Personally, I find having too many similar syntaxâs confusing - >>>> contributing to things is hard enough - having to remember that its >>>> !! Instead of ## and ââ instead of ** is just frustrating for me. >>>> >>>> My vote would be what Peter suggested - use >>>> http://spec.commonmark.org/0.28/ and put our Pillar extensions back >>>> on top for things that Stef was mentioning. (I think thatâs what Iâve >>>> understood gfm markdown is). >>>> >>>> Sure, maybe we were first with Pillar, but for me, lots of >>>> programming is in other languages, and I use Smalltalk where I can, >>>> and a hybrid of multiple languages and projects is often the reality >>>> - so a lowest common denominator of Markdown is just easier. The fact >>>> that we are quite close to what our colleagues in other languages use >>>> (regardless of what Python has chosen), is quite interesting. >>>> >>>> That said, if the community wants to stick to its gunâs thats fine - >>>> I will probably still investigate how to use Commonmark for myself, >>>> and will still contribute to Pillar docs where I can (and curse >>>> history) - but I think we are long better off trying to join emerging >>>> standards where we can particularly if they arenât our core language >>>> thing. And it just makes it less frictionless for ourselves and >>>> newcomers. >>>> >>>> Of course, if we were to move, we would need to translate a lot of >>>> quality docs to a new format - but I would be up for contributing to >>>> that if that was a deciding factor. >>>> >>>> Tim >>>> >>>> >>>>> On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com >>>>> <mailto:jlhouchin@gmail.com>> wrote: >>>>> >>>>> TL;DR >>>>> >>>>> Main points: >>>>> Their is no universally accepted markup language. >>>>> Other communities use their own markup and tools and their markup >>>>> and tools choice is not determine by other communities decisions. >>>>> We need a language and tool chain that we can control and maintain >>>>> which accomplishes our goals. >>>>> Our language and tools already exist and have existed for longer >>>>> than most of the other markup languages. Of course they existed in >>>>> various different forms over the years and have evolved into what >>>>> they currently are. >>>>> It might be nice to have a GFM Markdown exporter from Pillar for >>>>> GitHub projects. >>>>> >>>>> >>>>> I just want to comment on the fact that there is no universal markup >>>>> language that every development community has settled upon. Making >>>>> Markdown or some variant the markup language for Pharo only aligns >>>>> us with a certain part of the development community. Even Markdown >>>>> is not unified as is evident by the discussion. >>>>> >>>>> It is true that GitHub uses their variant of Markdown. And as long >>>>> as we use GitHub we will need to use their variant for documents >>>>> that reside on their system. >>>>> >>>>> However as a significant counter example to lets all use gfm >>>>> Markdown, is the Python community and their documentation. >>>>> >>>>> https://docs.python.org/devguide/documenting.html >>>>> """ >>>>> 7. Documenting Python >>>>> The Python language has a substantial body of documentation, much of >>>>> it contributed by various authors. The markup used for the Python >>>>> documentation is reStructuredText, developed by the docutils >>>>> project, amended by custom directives and using a toolset named >>>>> Sphinx to post-process the HTML output. >>>>> >>>>> This document describes the style guide for our documentation as >>>>> well as the custom reStructuredText markup introduced by Sphinx to >>>>> support Python documentation and how it should be used. >>>>> >>>>> The documentation in HTML, PDF or EPUB format is generated from text >>>>> files written using the reStructuredText format and contained in the >>>>> CPython Git repository. >>>>> """ >>>>> >>>>> So the Python community uses their own markup language and their own >>>>> tool chain. So therefore, it is not wrong for a community to go >>>>> their own way, for their own reasons. Even within the conventional >>>>> file based languages such as Python. >>>>> >>>>> The fact that you have tools such as Pandoc, suggest that there is >>>>> not true uniformity or unanimity among developers as to the best >>>>> markup language or tool chain. >>>>> >>>>> I believe that a language that we can control and maintain is better >>>>> than adopting some other foreign markup language that is neither >>>>> better, nor unanimously used by all. That would ultimately >>>>> potentially require extensions to accomplish our goals. Then we >>>>> would be maintaining someone else's language with our extensions >>>>> that may or may not be accepted by the larger community. This does >>>>> not prevent but rather encourages fragmentation of the existing >>>>> Markdown. >>>>> >>>>> Regardless, Pillar markup already exists. The tools in Pharo already >>>>> understand it. Should someone desire to use Pharo which is far more >>>>> different from Python/Ruby/etc. than Pillar syntax is from Markdown. >>>>> Then it should be worth their effort to learn our tools. >>>>> >>>>> Pillar markup is older than Markdown, etc. It's history begins in >>>>> SmallWiki. It isn't as if we jumped up and decided to create >>>>> something new in order to be different. Our markup and tools are >>>>> older. They (and others) are the ones that decided to do their own >>>>> markup and tools. And it is okay that they did so. Nothing wrong >>>>> with doing so. Every community has the right to what they believe is >>>>> best for their community. Even if other communities disagree. >>>>> >>>>> The ability to control and maintain is highly valuable. We can >>>>> understand what our requirements are for today. But we can not know >>>>> what the requirements are in the future. Nor can we know that >>>>> Markdown or whomever will have such requirements when they appear. >>>>> It is easy to see in the beginning with the Squeak Wiki syntax to >>>>> the now Pillar syntax, changes that have been made to accommodate >>>>> new requirements as they became known. We need to maintain that >>>>> ability. Sure we would reserve the right to do so in any language we >>>>> adopt. But the then current standard bearer of said language would >>>>> determine whether what we do is acceptable and incorporate or >>>>> whether we are then in fact adding to their fragmentation. Pillar is >>>>> ours. There is not fragmentation when we evolve. >>>>> >>>>> However, since we have made a decision to use GitHub and GitHub has >>>>> made a decision to use their own GFM Markdown. It might be nice to >>>>> have a GFM Markdown exporter from Pillar for GitHub projects. This >>>>> way we can use our own tools and markup language to accomplish >>>>> whatever we want to accomplish. Including generating a Readme.md for >>>>> our GitHub projects. >>>>> >>>>> Just wanted to toss out this simple opinion and facts about the >>>>> situation. >>>>> >>>>> Jimmie >>>>> >>>>> >>>>> On 08/14/2017 04:10 AM, Tudor Girba wrote: >>>>>> Hi Tim, >>>>>> >>>>>> The main benefit of relying on Pillar is that we control its syntax >>>>>> and can easily extend it for our purposes. Also, there was quite a >>>>>> bit of engineering invested in it, and even though we still need to >>>>>> improve it, there exists a pipeline that allows people to quickly >>>>>> publish books. >>>>>> >>>>>> The figure embedding problem is one example of the need to >>>>>> customize the syntax and behavior, but this extensibility will >>>>>> become even more important for supporting the idea of moving the >>>>>> documentation inside the image. For example, the ability to refer >>>>>> to a class, method or other artifacts will be quite relevant soon >>>>>> especially that the editor will be able to embed advanced elements >>>>>> inside the text. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Stef - I think yourâs is a fair requirement (in fact I hit >>>>>>> something similar when doing a static website using a JS markdown >>>>>>> framework - and this is why I mentioned Kramdown which adds a few >>>>>>> extras to regular markdown - but it feels like it goes a bit too >>>>>>> far). >>>>>>> >>>>>>> My next item on my learning todo list was to try and replace that >>>>>>> JS generator with something from Smalltalk - so I think we can >>>>>>> possibly come up with something that ticks all the right boxes >>>>>>> (Iâd like to try anyway). >>>>>>> >>>>>>> Iâll keep working away on it and compare notes with you. I think >>>>>>> with Pillar, it was more that things like headers, bold and >>>>>>> italics are similar concepts but just use different characters - >>>>>>> so I keep typing the wrong thing and getting frustrated >>>>>>> particularly when we embrace Git and readme.md is in markdown. >>>>>>> >>>>>>> >>>>>>> Tim >>>>>>> >>>>>>>> On 13 Aug 2017, at 20:08, Stephane Ducasse >>>>>>>> <stepharo.self(a)gmail.com> wrote: >>>>>>>> >>>>>>>> Hi tim >>>>>>>> >>>>>>>> I personally do not care much about the syntax but I care about >>>>>>>> what I >>>>>>>> can do with it >>>>>>>> (ref, cite, ... ) >>>>>>>> I cannot write books in markdown because reference to figures!!!!!! >>>>>>>> were missing. >>>>>>>> >>>>>>>> And of course a parser because markdown is not really nice to parse >>>>>>>> and I will not write a parser because I have something else to do. >>>>>>>> I >>>>>>>> want to make pillar smaller, simpler, nicer. >>>>>>>> >>>>>>>> Now if someone come up with a parser that parse for REAL a markdown >>>>>>>> that can be extended with decent behavior (figure reference, >>>>>>>> section >>>>>>>> reference, cite) and can be extended because there are many things >>>>>>>> that can be nice to have (for example I want to be able to write >>>>>>>> the >>>>>>>> example below) and emit a PillarModel (AST) we can talk to have >>>>>>>> another syntax for Pillar but not before. >>>>>>>> >>>>>>>> [[[test >>>>>>>> 2+3 >>>>>>>>>>> 5 >>>>>>>> ]]] >>>>>>>> >>>>>>>> and being able to verify that the doc is in sync. >>>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon >>>>>>>> <tim(a)testit.works> wrote: >>>>>>>>> Of course, I/we recognise and appreciate all the work that's >>>>>>>>> gone into docs in pillar - but I think it should be reasonably >>>>>>>>> straightforward to write a converter as it is pretty closely >>>>>>>>> related from what I have seen. >>>>>>>>> >>>>>>>>> So I don't make the suggestion flippantly, and would want to >>>>>>>>> help write a converter and get us to a common ground where we >>>>>>>>> can differentiate on the aspects where we can excel. >>>>>>>>> >>>>>>>>> Tim >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> A long time issue with Markdown was that there was no >>>>>>>>>> standardization (and when I used Pillar's MD export ~2 years >>>>>>>>>> ago it didn't work well). >>>>>>>>>> >>>>>>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has >>>>>>>>>> become the de-facto standard, so it would make sense to support >>>>>>>>>> it bidirectionally with Pillar. >>>>>>>>>> >>>>>>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>>>>>> Well, technically it is just a CommonMark, as I am not using >>>>>>>>>> any github extensions. >>>>>>>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>>>>>>> >>>>>>>>>> Peter >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.feenk.com >>>>>> >>>>>> âLive like you mean it." >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> >

Aug. 15, 2017

Re: [Pharo-users] [Pharo-dev] including Pillar in Pharo image by default

by H. Hirzel

Offray, thanks for the nice write-up about the general usefulness of Markdown for writing papers. Stephen D. wrote yesterday in a terse way "We can change the syntax or propose an alternate one as soon as it uses the same internal structure. Stef" This means that Pillars tagging system may be changed to a more generally known tagging system later. I assume with 'internal structure' he refers to the AST/Document Object Model of Pillar which would need to be aligned with one of another markup system. Maybe the gap is not all that large. Personally I think as well that if Pharo could also be used as a markdown (commonmark) editor with its tool-chain to generate different types of documents would expand the area of application considerably. --Hannes On 8/15/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi, > > While I appreciate the historical perspective, I continue to be with Tim > on this (and I consider myself part of the Pharo Community). I have also > personal preferences for other light markup languages (like txt2tags[1] > and dokuwiki's[2]), but I will stick with Pandoc's Markdown, because is > support everything Stephan or any professional author wants to do and in > fact you can create full books with it, including references, tables, > images, and bibliographic references (which are not supported by Pillar > AFAIK), but also because is an emerging standard beyond the programmers > community, including academicians and researchers with the Scholarly > Markdown[3] initiative and with possibilities to import and export > from/to several markup languages[4]. > > [1] http://txt2tags.org/ > [2] https://www.dokuwiki.org/wiki:syntax > [3] http://scholmd.org/ > [4] http://pandoc.org/ > > I don't share the vision of particular communities choosing particular > markup languages as default, because, if you already payed the price of > learning that particular language/environment, you are willing to pay > the price with whatever that community choose in other fronts like DVCS > or markup languages. Python community supports reST, but also markdown > and several other markup languages and Jupyter notebooks[5] user > Markdown by default. In fact, the Iceberg Git support shows the > increasing concern to bridge the Pharo world with the stuff you already > know and I think that a similar approach should be taken in the > documentation/markup front, even if this implies breaking compatibility > with the canonical Smalltalk way (TM) (I really like that critical > approach from Pharo to the past). > > [5] http://jupyter.org/ > > That being said, I don't think that should be exclusively one way or > another. We can have Pillar and (Pandoc's) Markdown, if the community > doesn't reach and agreement on only one. > > I plan to explore the Brick editor once I have time and will try to add > Pandoc's Markdown support. Unfortunately, in the past I have not had > many luck testing and giving feedback on Moose alpha releases of tools > and my questions/comments on them remain largely unanswered or simply > ignored for long time (or just forever), so my priority on testing these > tools have just decreased, but once Brick editor become more well > supported, Pandoc's Markdown support for it will be in my target and > concerns. > > Cheers, > > Offray > > On 14/08/17 12:48, Jimmie Houchin wrote: >> >> Thank Tim, >> >> My primary reason to submit the message was not to necessarily >> persuade you per se. But to provide something historical for the >> mailing list as this can be a recurring subject. Why use Pillar markup >> instead of ???(insert personal favorite). >> >> If Pharo were to decide on a different markup language. The question >> would still be which one, why and then how do we proceed. Then our >> extensions may not be accepted by the greater body of users of said >> markup. We would still be contributing to the fragmentation of markup. >> As far as familiarity, I don't know. And familiarity with what. I do >> not find that reStructuredText to be similar to Markdown. >> >> It would stop people from asking why we aren't using Markdown. But it >> wouldn't prevent others. Why aren't we using GFM Markdown, or Kramdown >> or Commonmark or ...? Why aren't we using YAML or reST or AsciiDoc or >> insert latest greatest creation markup or current flavor of the >> moment. Which is why I wanted to point out that there is no consensus >> among users of markup languages. At least I do not see one. Nor do I >> believe that we have seen the end of creation of new markup languages. >> >> I understand the difficulty, though I do not suffer from it as I have >> not mastered any of those other languages. I have been using >> Squeak/Pharo for a long time. I struggle when I look at those other >> languages. To me they are the foreign ones. >> >> And I do not see these emerging standards you refer to. When we see >> Python, Ruby, Perl, C++, various projects, etc. communities having >> consensus on a common markup for documentation. Then I see an emerging >> standard. Until then it seems to possibly be an emerging standard for >> a particular markup language which is among the set of markup languages. >> >> If we were the only language and development environment doing our own >> thing. Then we might have a very good reason to talk. But we are not. >> Python with its enormous community does its own thing. I don't know >> that other languages have a consensus for markup for documentation >> except for Python and Pharo. >> >> While writing this email I went and discovered that even GitHub is not >> dogmatic about the subject. Obviously they have an opinion. But they >> permit multiple markup languages. Quite possibly someone could write a >> Pillar tool for GitHub to use and then we could just submit >> Readme.pillar for our projects. :) >> >> https://github.com/github/markup >> >> Shows that GitHub allows for .markdown, .mdown, .mkdn, .md; .textile; >> .rdoc; .org; .creole; .mediawiki, .wiki; .rst; .asciidoc, .adoc, .asc; >> .pod. So it seems that there are many communities on GitHub who >> prefer their own markup and tools. >> >> We could possibly write the Pillar tool for GitHub or an exporter to >> the preferred markup language of the above. >> >> This author provides arguments for using reStructuredText over >> Markdown for GitHub documents. Citing deficiencies in Markdown and >> expressiveness in reST. >> >> https://gist.github.com/dupuy/1855764 >> >> So again. I am just not seeing a consensus around any emerging >> standard for "the markup language". >> >> At the same time if you are desirous of writing in Commonmark in your >> text editor. Can you not write conversion software that goes from >> Commonmark to Pillar? Thus, meeting want you want and what we require? >> If you were to do so, you would definitely have a good understanding >> of the differences in philosophy and capabilities of each. Just a >> thought. >> >> Any way, thanks for engaging in the conversation. I wasn't targeting >> you personally, but rather the topic. You are not alone in your >> thinking. The Pharo community is not alone in its thinking either. >> >> Thanks. >> >> Jimmie >> >> >> >> >> On 08/14/2017 11:34 AM, Tim Mackinnon wrote: >>> Jimmie et al. nicely reasoned arguments - and Doru's point about >>> controlling the syntax is an interesting one that I hadnât thought >>> about. >>> >>> Personally, I find having too many similar syntaxâs confusing - >>> contributing to things is hard enough - having to remember that its >>> !! Instead of ## and ââ instead of ** is just frustrating for me. >>> >>> My vote would be what Peter suggested - use >>> http://spec.commonmark.org/0.28/ and put our Pillar extensions back >>> on top for things that Stef was mentioning. (I think thatâs what Iâve >>> understood gfm markdown is). >>> >>> Sure, maybe we were first with Pillar, but for me, lots of >>> programming is in other languages, and I use Smalltalk where I can, >>> and a hybrid of multiple languages and projects is often the reality >>> - so a lowest common denominator of Markdown is just easier. The fact >>> that we are quite close to what our colleagues in other languages use >>> (regardless of what Python has chosen), is quite interesting. >>> >>> That said, if the community wants to stick to its gunâs thats fine - >>> I will probably still investigate how to use Commonmark for myself, >>> and will still contribute to Pillar docs where I can (and curse >>> history) - but I think we are long better off trying to join emerging >>> standards where we can particularly if they arenât our core language >>> thing. And it just makes it less frictionless for ourselves and >>> newcomers. >>> >>> Of course, if we were to move, we would need to translate a lot of >>> quality docs to a new format - but I would be up for contributing to >>> that if that was a deciding factor. >>> >>> Tim >>> >>> >>>> On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com >>>> <mailto:jlhouchin@gmail.com>> wrote: >>>> >>>> TL;DR >>>> >>>> Main points: >>>> Their is no universally accepted markup language. >>>> Other communities use their own markup and tools and their markup >>>> and tools choice is not determine by other communities decisions. >>>> We need a language and tool chain that we can control and maintain >>>> which accomplishes our goals. >>>> Our language and tools already exist and have existed for longer >>>> than most of the other markup languages. Of course they existed in >>>> various different forms over the years and have evolved into what >>>> they currently are. >>>> It might be nice to have a GFM Markdown exporter from Pillar for >>>> GitHub projects. >>>> >>>> >>>> I just want to comment on the fact that there is no universal markup >>>> language that every development community has settled upon. Making >>>> Markdown or some variant the markup language for Pharo only aligns >>>> us with a certain part of the development community. Even Markdown >>>> is not unified as is evident by the discussion. >>>> >>>> It is true that GitHub uses their variant of Markdown. And as long >>>> as we use GitHub we will need to use their variant for documents >>>> that reside on their system. >>>> >>>> However as a significant counter example to lets all use gfm >>>> Markdown, is the Python community and their documentation. >>>> >>>> https://docs.python.org/devguide/documenting.html >>>> """ >>>> 7. Documenting Python >>>> The Python language has a substantial body of documentation, much of >>>> it contributed by various authors. The markup used for the Python >>>> documentation is reStructuredText, developed by the docutils >>>> project, amended by custom directives and using a toolset named >>>> Sphinx to post-process the HTML output. >>>> >>>> This document describes the style guide for our documentation as >>>> well as the custom reStructuredText markup introduced by Sphinx to >>>> support Python documentation and how it should be used. >>>> >>>> The documentation in HTML, PDF or EPUB format is generated from text >>>> files written using the reStructuredText format and contained in the >>>> CPython Git repository. >>>> """ >>>> >>>> So the Python community uses their own markup language and their own >>>> tool chain. So therefore, it is not wrong for a community to go >>>> their own way, for their own reasons. Even within the conventional >>>> file based languages such as Python. >>>> >>>> The fact that you have tools such as Pandoc, suggest that there is >>>> not true uniformity or unanimity among developers as to the best >>>> markup language or tool chain. >>>> >>>> I believe that a language that we can control and maintain is better >>>> than adopting some other foreign markup language that is neither >>>> better, nor unanimously used by all. That would ultimately >>>> potentially require extensions to accomplish our goals. Then we >>>> would be maintaining someone else's language with our extensions >>>> that may or may not be accepted by the larger community. This does >>>> not prevent but rather encourages fragmentation of the existing >>>> Markdown. >>>> >>>> Regardless, Pillar markup already exists. The tools in Pharo already >>>> understand it. Should someone desire to use Pharo which is far more >>>> different from Python/Ruby/etc. than Pillar syntax is from Markdown. >>>> Then it should be worth their effort to learn our tools. >>>> >>>> Pillar markup is older than Markdown, etc. It's history begins in >>>> SmallWiki. It isn't as if we jumped up and decided to create >>>> something new in order to be different. Our markup and tools are >>>> older. They (and others) are the ones that decided to do their own >>>> markup and tools. And it is okay that they did so. Nothing wrong >>>> with doing so. Every community has the right to what they believe is >>>> best for their community. Even if other communities disagree. >>>> >>>> The ability to control and maintain is highly valuable. We can >>>> understand what our requirements are for today. But we can not know >>>> what the requirements are in the future. Nor can we know that >>>> Markdown or whomever will have such requirements when they appear. >>>> It is easy to see in the beginning with the Squeak Wiki syntax to >>>> the now Pillar syntax, changes that have been made to accommodate >>>> new requirements as they became known. We need to maintain that >>>> ability. Sure we would reserve the right to do so in any language we >>>> adopt. But the then current standard bearer of said language would >>>> determine whether what we do is acceptable and incorporate or >>>> whether we are then in fact adding to their fragmentation. Pillar is >>>> ours. There is not fragmentation when we evolve. >>>> >>>> However, since we have made a decision to use GitHub and GitHub has >>>> made a decision to use their own GFM Markdown. It might be nice to >>>> have a GFM Markdown exporter from Pillar for GitHub projects. This >>>> way we can use our own tools and markup language to accomplish >>>> whatever we want to accomplish. Including generating a Readme.md for >>>> our GitHub projects. >>>> >>>> Just wanted to toss out this simple opinion and facts about the >>>> situation. >>>> >>>> Jimmie >>>> >>>> >>>> On 08/14/2017 04:10 AM, Tudor Girba wrote: >>>>> Hi Tim, >>>>> >>>>> The main benefit of relying on Pillar is that we control its syntax >>>>> and can easily extend it for our purposes. Also, there was quite a >>>>> bit of engineering invested in it, and even though we still need to >>>>> improve it, there exists a pipeline that allows people to quickly >>>>> publish books. >>>>> >>>>> The figure embedding problem is one example of the need to >>>>> customize the syntax and behavior, but this extensibility will >>>>> become even more important for supporting the idea of moving the >>>>> documentation inside the image. For example, the ability to refer >>>>> to a class, method or other artifacts will be quite relevant soon >>>>> especially that the editor will be able to embed advanced elements >>>>> inside the text. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>>>> >>>>>> Hi Stef - I think yourâs is a fair requirement (in fact I hit >>>>>> something similar when doing a static website using a JS markdown >>>>>> framework - and this is why I mentioned Kramdown which adds a few >>>>>> extras to regular markdown - but it feels like it goes a bit too >>>>>> far). >>>>>> >>>>>> My next item on my learning todo list was to try and replace that >>>>>> JS generator with something from Smalltalk - so I think we can >>>>>> possibly come up with something that ticks all the right boxes >>>>>> (Iâd like to try anyway). >>>>>> >>>>>> Iâll keep working away on it and compare notes with you. I think >>>>>> with Pillar, it was more that things like headers, bold and >>>>>> italics are similar concepts but just use different characters - >>>>>> so I keep typing the wrong thing and getting frustrated >>>>>> particularly when we embrace Git and readme.md is in markdown. >>>>>> >>>>>> >>>>>> Tim >>>>>> >>>>>>> On 13 Aug 2017, at 20:08, Stephane Ducasse >>>>>>> <stepharo.self(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi tim >>>>>>> >>>>>>> I personally do not care much about the syntax but I care about >>>>>>> what I >>>>>>> can do with it >>>>>>> (ref, cite, ... ) >>>>>>> I cannot write books in markdown because reference to figures!!!!!! >>>>>>> were missing. >>>>>>> >>>>>>> And of course a parser because markdown is not really nice to parse >>>>>>> and I will not write a parser because I have something else to do. I >>>>>>> want to make pillar smaller, simpler, nicer. >>>>>>> >>>>>>> Now if someone come up with a parser that parse for REAL a markdown >>>>>>> that can be extended with decent behavior (figure reference, section >>>>>>> reference, cite) and can be extended because there are many things >>>>>>> that can be nice to have (for example I want to be able to write the >>>>>>> example below) and emit a PillarModel (AST) we can talk to have >>>>>>> another syntax for Pillar but not before. >>>>>>> >>>>>>> [[[test >>>>>>> 2+3 >>>>>>>>>> 5 >>>>>>> ]]] >>>>>>> >>>>>>> and being able to verify that the doc is in sync. >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon >>>>>>> <tim(a)testit.works> wrote: >>>>>>>> Of course, I/we recognise and appreciate all the work that's >>>>>>>> gone into docs in pillar - but I think it should be reasonably >>>>>>>> straightforward to write a converter as it is pretty closely >>>>>>>> related from what I have seen. >>>>>>>> >>>>>>>> So I don't make the suggestion flippantly, and would want to >>>>>>>> help write a converter and get us to a common ground where we >>>>>>>> can differentiate on the aspects where we can excel. >>>>>>>> >>>>>>>> Tim >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> A long time issue with Markdown was that there was no >>>>>>>>> standardization (and when I used Pillar's MD export ~2 years >>>>>>>>> ago it didn't work well). >>>>>>>>> >>>>>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has >>>>>>>>> become the de-facto standard, so it would make sense to support >>>>>>>>> it bidirectionally with Pillar. >>>>>>>>> >>>>>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>>>>> Well, technically it is just a CommonMark, as I am not using >>>>>>>>> any github extensions. >>>>>>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>> >>>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> âLive like you mean it." >>>>> >>>>> >>>> >>>> >>> >> > >

Aug. 15, 2017

Re: [Pharo-users] [ANN] VistaCursor now scalable

by webwarrior

Torsten Bergmann wrote > Hi, > > Mike Davis asked about changing the cursor size as he runs Pharo with > Windows 10 on a Microsoft Surface > @ 2736 x 1824 dpi. He discussed on Discord and said that all of the > display is well scaled, except the mouse > cursor which is too small for him. > > As the Windows VM supports larger cursors I added some support to my > loadable goodie package "VistaCursor" now. > So there is now a new setting to scale the provided cursors (see > screenshots). Either freshly load the package > from catalog or update to "VistaCursors-TorstenBergmann.5" if you want to > check this out. > > This might be also be useful for presentations. > > Have fun > T. > > > vistacursor.png (37K) > <http://forum.world.st/attachment/4961238/0/vistacursor.png> This only partly fixes the problem. Not all cursors are replaced - e.g. cursor for text selection is sitll tiny. Also seting has to be changed every time someone switches to another computer or even to another display with different DPI. I opened an issue in bugtracker (https://pharo.fogbugz.com/f/cases/20281/Small-cursor-on-high-DPI-displays-i…) some time ago, but nobody has reacted yet. -- View this message in context: http://forum.world.st/ANN-VistaCursor-now-scalable-tp4961238p4961322.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 15, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Guillermo Polito

On Mon, Aug 14, 2017 at 4:42 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hi Guille - just running SpaceTally on my dev image to get a feel for it. > It turns out that in the minimal images youâve been creating, its not > loaded (makes sense). > Yup, it's loaded afterwards. All packages are loaded through metacello baselines. We should start refactoring and making standalone projects, each one with a baseline for himself, and his own dependencies described. I was checking on your gitlab and I have probably no access: how are you finally loading packages in the bootstrap image? Can you share that with us in text? I'd like to improve that situation. > Iâm wondering if there is an easy way to import it in (I guess that > package should be in the Pharo git tree I cloned to get Fuel loaded right? > Or is there a separate standalone source?). > Yes it is, you can get the package programatically doing SpaceTally package name And furthermore, get the baseline that currently is loading by doing package := SpaceTally package name. BaselineOf subclasses select: [ :e | e project version packages anySatisfy: [ :p | p name = package ]]. > > Thanks for all the support, and your email about why the contexts stack up > is very well received (I will comment over there). > > By the way - it looks like Martin Fowler picked up on this announcement - > so maybe we might get some interest from his mass of followers. > > Tim > > On 14 Aug 2017, at 10:49, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi Tim, > > On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hey guys, thanks for your enthusiasm around this - and I cannot stress >> enough how this was only possible because of the work that has gone into >> making Pharo (in particular the 64bit image, as well as having a minimal >> image, and some great blog posts on serialising contexts) as well as the >> patience from everyone in answering questions and helping me get it all >> working. >> >> Iâm still quite keen to get my execution time back down under 800ms and >> Iâd like to actually get back to writing a few skills to automate a few >> things around my house. >> >> To Answer Denisâ question - >> >> My final footprint is 30.4mb - thats composed of a 22mb image (with a >> simple example that pulls in Fuel, ZTimestamp and the S3 Library which >> depends on XMLParser) and then the VM (from which I removed obvious dllâs). >> >> In my original experiments with a 6.0 minimal image - I did manage to get >> to a 13.4mb image (which started out as 12mb original size, and then loaded >> in STON and had only a simple clock example). I think the sweet spot is >> around 20mb total footprint as that seems to get me into the 450ms-900ms >> range. >> >> The 7.0 min image now starts out at 15mb and then Iâm not sure why >> loading Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not >> dug into that). >> > > You can do further space analysis using the following expression > > SpaceTally new printSpaceAnalysis > > You can do that in an eval and check what's taking space. With measures we > can iterate and improve :). > > >> Iâve also found (and this on the back of unserialising the context in my >> example) that the way we build images has 15+ saved stack sessions that >> have saved on top of each other from the way we build up the images. I >> donât yet know the implications of size/speed of these - but we need a >> better way of folding executions when we snapshot headless images. Iâm also >> not clear if there are any other startup tasks that take precious time >> (this also has implications for our fat development images as they take >> much longer to appear than they really should). >> > > I'm working on this as I'm writing this mail ;) > > https://pharo.fogbugz.com/f/cases/20309 > https://github.com/pharo-project/pharo/pull/196 > > I'll write down the implications further in a different thread. > > >> Iâll be exploring some of these size/speed tradeoffâs in follow on >> messages. >> >> But once again, a big thanks - Iâve not enjoyed programming like this for >> ages. >> >> Tim >> >> On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com> wrote: >> >> hi Tim, >> >> That is..... AWESOME! >> >> Very nice delivery - it flowed well with great narration. >> >> I loved @2:17 "this is the interesting piece, because PharoLambda has >> serialized the execution context of its application and saved it into [my >> S3 bucket] ... [then on the local machine] rematerializes a debugger [on >> that context]." >> >> There is a clarity in your video presentation that really may intrigue >> outsiders. As a community we should push this on the usual hacker forums - >> ycombinator could be a good starting point (but I'm locked out of my >> account there). >> An enticing title could be... >> "Debugging Lambdas by re-materializing saved execution contexts on your >> local machine." >> >> cheers -ben >> >> On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> This is cool Tim. >>> >>> So what image size you deployed at the end? >>> >>> 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> I just wanted to thank everyone for their help in getting my pet >>>> project further along, so that now I can announce that PharoLambda is now >>>> working with the V7 minimal image and also supports post mortem debugging >>>> by saving a zipped fuel context onto S3. >>>> >>>> This latter item is particularly satisfying as at a recent serverless >>>> conference (JeffConf) there was a panel where poor development tools on >>>> serverless platforms was highlighted as a real problem. >>>> >>>> In our community weâve had these kinds of tools at our fingertips for >>>> ages - but I donât think the wider development community has really >>>> noticed. Debugging something short lived like a Lambda execution is quite >>>> startling, as the current answer is âadd more loggingâ, and we all know >>>> that sucks. To this end, Iâve created a little screencast showing this in >>>> action - and it was pretty cool because it was a real example I encountered >>>> when I got everything working and was trying my test application out. >>>> >>>> Iâve also put a bit of work into tuning the excellent GitLab CI tools, >>>> so that I can cache many of the artefacts used between different build runs >>>> (this might also be of interest to others using CI systems). >>>> >>>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda >>>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E >>>> >>>> Tim >>>> >>>> >>>> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> Hi - Iâve been playing around with getting Pharo to run well on AWS >>>> Lambda. Itâs early days, but I though it might be interesting to share what >>>> Iâve learned so far. >>>> >>>> Usage examples and code at https://gitlab.com/macta/PharoLambda >>>> >>>> With help from many of the folks here, Iâve been able to get a simple >>>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily >>>> try it out yourself. This seems slightly better than what the GoLang folks >>>> have been able to do. >>>> >>>> Tim >>>> >>>> >>>> >>> >> >> > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr/> > > > *Web:* *http://guillep.github.io* <http://guillep.github.io/> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 15, 2017

Re: [Pharo-users] [Pharo-dev] including Pillar in Pharo image by default

by Offray Vladimir Luna CÃ¡rdenas

Hi, While I appreciate the historical perspective, I continue to be with Tim on this (and I consider myself part of the Pharo Community). I have also personal preferences for other light markup languages (like txt2tags[1] and dokuwiki's[2]), but I will stick with Pandoc's Markdown, because is support everything Stephan or any professional author wants to do and in fact you can create full books with it, including references, tables, images, and bibliographic references (which are not supported by Pillar AFAIK), but also because is an emerging standard beyond the programmers community, including academicians and researchers with the Scholarly Markdown[3] initiative and with possibilities to import and export from/to several markup languages[4]. [1] http://txt2tags.org/ [2] https://www.dokuwiki.org/wiki:syntax [3] http://scholmd.org/ [4] http://pandoc.org/ I don't share the vision of particular communities choosing particular markup languages as default, because, if you already payed the price of learning that particular language/environment, you are willing to pay the price with whatever that community choose in other fronts like DVCS or markup languages. Python community supports reST, but also markdown and several other markup languages and Jupyter notebooks[5] user Markdown by default. In fact, the Iceberg Git support shows the increasing concern to bridge the Pharo world with the stuff you already know and I think that a similar approach should be taken in the documentation/markup front, even if this implies breaking compatibility with the canonical Smalltalk way (TM) (I really like that critical approach from Pharo to the past). [5] http://jupyter.org/ That being said, I don't think that should be exclusively one way or another. We can have Pillar and (Pandoc's) Markdown, if the community doesn't reach and agreement on only one. I plan to explore the Brick editor once I have time and will try to add Pandoc's Markdown support. Unfortunately, in the past I have not had many luck testing and giving feedback on Moose alpha releases of tools and my questions/comments on them remain largely unanswered or simply ignored for long time (or just forever), so my priority on testing these tools have just decreased, but once Brick editor become more well supported, Pandoc's Markdown support for it will be in my target and concerns. Cheers, Offray On 14/08/17 12:48, Jimmie Houchin wrote: > > Thank Tim, > > My primary reason to submit the message was not to necessarily > persuade you per se. But to provide something historical for the > mailing list as this can be a recurring subject. Why use Pillar markup > instead of ???(insert personal favorite). > > If Pharo were to decide on a different markup language. The question > would still be which one, why and then how do we proceed. Then our > extensions may not be accepted by the greater body of users of said > markup. We would still be contributing to the fragmentation of markup. > As far as familiarity, I don't know. And familiarity with what. I do > not find that reStructuredText to be similar to Markdown. > > It would stop people from asking why we aren't using Markdown. But it > wouldn't prevent others. Why aren't we using GFM Markdown, or Kramdown > or Commonmark or ...? Why aren't we using YAML or reST or AsciiDoc or > insert latest greatest creation markup or current flavor of the > moment. Which is why I wanted to point out that there is no consensus > among users of markup languages. At least I do not see one. Nor do I > believe that we have seen the end of creation of new markup languages. > > I understand the difficulty, though I do not suffer from it as I have > not mastered any of those other languages. I have been using > Squeak/Pharo for a long time. I struggle when I look at those other > languages. To me they are the foreign ones. > > And I do not see these emerging standards you refer to. When we see > Python, Ruby, Perl, C++, various projects, etc. communities having > consensus on a common markup for documentation. Then I see an emerging > standard. Until then it seems to possibly be an emerging standard for > a particular markup language which is among the set of markup languages. > > If we were the only language and development environment doing our own > thing. Then we might have a very good reason to talk. But we are not. > Python with its enormous community does its own thing. I don't know > that other languages have a consensus for markup for documentation > except for Python and Pharo. > > While writing this email I went and discovered that even GitHub is not > dogmatic about the subject. Obviously they have an opinion. But they > permit multiple markup languages. Quite possibly someone could write a > Pillar tool for GitHub to use and then we could just submit > Readme.pillar for our projects. :) > > https://github.com/github/markup > > Shows that GitHub allows for .markdown, .mdown, .mkdn, .md; .textile; > .rdoc; .org; .creole; .mediawiki, .wiki; .rst; .asciidoc, .adoc, .asc; > .pod. So it seems that there are many communities on GitHub who > prefer their own markup and tools. > > We could possibly write the Pillar tool for GitHub or an exporter to > the preferred markup language of the above. > > This author provides arguments for using reStructuredText over > Markdown for GitHub documents. Citing deficiencies in Markdown and > expressiveness in reST. > > https://gist.github.com/dupuy/1855764 > > So again. I am just not seeing a consensus around any emerging > standard for "the markup language". > > At the same time if you are desirous of writing in Commonmark in your > text editor. Can you not write conversion software that goes from > Commonmark to Pillar? Thus, meeting want you want and what we require? > If you were to do so, you would definitely have a good understanding > of the differences in philosophy and capabilities of each. Just a thought. > > Any way, thanks for engaging in the conversation. I wasn't targeting > you personally, but rather the topic. You are not alone in your > thinking. The Pharo community is not alone in its thinking either. > > Thanks. > > Jimmie > > > > > On 08/14/2017 11:34 AM, Tim Mackinnon wrote: >> Jimmie et al. nicely reasoned arguments - and Doru's point about >> controlling the syntax is an interesting one that I hadnât thought >> about. >> >> Personally, I find having too many similar syntaxâs confusing - >> contributing to things is hard enough - having to remember that its >> !! Instead of ## and ââ instead of ** is just frustrating for me. >> >> My vote would be what Peter suggested - use >> http://spec.commonmark.org/0.28/ and put our Pillar extensions back >> on top for things that Stef was mentioning. (I think thatâs what Iâve >> understood gfm markdown is). >> >> Sure, maybe we were first with Pillar, but for me, lots of >> programming is in other languages, and I use Smalltalk where I can, >> and a hybrid of multiple languages and projects is often the reality >> - so a lowest common denominator of Markdown is just easier. The fact >> that we are quite close to what our colleagues in other languages use >> (regardless of what Python has chosen), is quite interesting. >> >> That said, if the community wants to stick to its gunâs thats fine - >> I will probably still investigate how to use Commonmark for myself, >> and will still contribute to Pillar docs where I can (and curse >> history) - but I think we are long better off trying to join emerging >> standards where we can particularly if they arenât our core language >> thing. And it just makes it less frictionless for ourselves and >> newcomers. >> >> Of course, if we were to move, we would need to translate a lot of >> quality docs to a new format - but I would be up for contributing to >> that if that was a deciding factor. >> >> Tim >> >> >>> On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com >>> <mailto:jlhouchin@gmail.com>> wrote: >>> >>> TL;DR >>> >>> Main points: >>> Their is no universally accepted markup language. >>> Other communities use their own markup and tools and their markup >>> and tools choice is not determine by other communities decisions. >>> We need a language and tool chain that we can control and maintain >>> which accomplishes our goals. >>> Our language and tools already exist and have existed for longer >>> than most of the other markup languages. Of course they existed in >>> various different forms over the years and have evolved into what >>> they currently are. >>> It might be nice to have a GFM Markdown exporter from Pillar for >>> GitHub projects. >>> >>> >>> I just want to comment on the fact that there is no universal markup >>> language that every development community has settled upon. Making >>> Markdown or some variant the markup language for Pharo only aligns >>> us with a certain part of the development community. Even Markdown >>> is not unified as is evident by the discussion. >>> >>> It is true that GitHub uses their variant of Markdown. And as long >>> as we use GitHub we will need to use their variant for documents >>> that reside on their system. >>> >>> However as a significant counter example to lets all use gfm >>> Markdown, is the Python community and their documentation. >>> >>> https://docs.python.org/devguide/documenting.html >>> """ >>> 7. Documenting Python >>> The Python language has a substantial body of documentation, much of >>> it contributed by various authors. The markup used for the Python >>> documentation is reStructuredText, developed by the docutils >>> project, amended by custom directives and using a toolset named >>> Sphinx to post-process the HTML output. >>> >>> This document describes the style guide for our documentation as >>> well as the custom reStructuredText markup introduced by Sphinx to >>> support Python documentation and how it should be used. >>> >>> The documentation in HTML, PDF or EPUB format is generated from text >>> files written using the reStructuredText format and contained in the >>> CPython Git repository. >>> """ >>> >>> So the Python community uses their own markup language and their own >>> tool chain. So therefore, it is not wrong for a community to go >>> their own way, for their own reasons. Even within the conventional >>> file based languages such as Python. >>> >>> The fact that you have tools such as Pandoc, suggest that there is >>> not true uniformity or unanimity among developers as to the best >>> markup language or tool chain. >>> >>> I believe that a language that we can control and maintain is better >>> than adopting some other foreign markup language that is neither >>> better, nor unanimously used by all. That would ultimately >>> potentially require extensions to accomplish our goals. Then we >>> would be maintaining someone else's language with our extensions >>> that may or may not be accepted by the larger community. This does >>> not prevent but rather encourages fragmentation of the existing >>> Markdown. >>> >>> Regardless, Pillar markup already exists. The tools in Pharo already >>> understand it. Should someone desire to use Pharo which is far more >>> different from Python/Ruby/etc. than Pillar syntax is from Markdown. >>> Then it should be worth their effort to learn our tools. >>> >>> Pillar markup is older than Markdown, etc. It's history begins in >>> SmallWiki. It isn't as if we jumped up and decided to create >>> something new in order to be different. Our markup and tools are >>> older. They (and others) are the ones that decided to do their own >>> markup and tools. And it is okay that they did so. Nothing wrong >>> with doing so. Every community has the right to what they believe is >>> best for their community. Even if other communities disagree. >>> >>> The ability to control and maintain is highly valuable. We can >>> understand what our requirements are for today. But we can not know >>> what the requirements are in the future. Nor can we know that >>> Markdown or whomever will have such requirements when they appear. >>> It is easy to see in the beginning with the Squeak Wiki syntax to >>> the now Pillar syntax, changes that have been made to accommodate >>> new requirements as they became known. We need to maintain that >>> ability. Sure we would reserve the right to do so in any language we >>> adopt. But the then current standard bearer of said language would >>> determine whether what we do is acceptable and incorporate or >>> whether we are then in fact adding to their fragmentation. Pillar is >>> ours. There is not fragmentation when we evolve. >>> >>> However, since we have made a decision to use GitHub and GitHub has >>> made a decision to use their own GFM Markdown. It might be nice to >>> have a GFM Markdown exporter from Pillar for GitHub projects. This >>> way we can use our own tools and markup language to accomplish >>> whatever we want to accomplish. Including generating a Readme.md for >>> our GitHub projects. >>> >>> Just wanted to toss out this simple opinion and facts about the >>> situation. >>> >>> Jimmie >>> >>> >>> On 08/14/2017 04:10 AM, Tudor Girba wrote: >>>> Hi Tim, >>>> >>>> The main benefit of relying on Pillar is that we control its syntax >>>> and can easily extend it for our purposes. Also, there was quite a >>>> bit of engineering invested in it, and even though we still need to >>>> improve it, there exists a pipeline that allows people to quickly >>>> publish books. >>>> >>>> The figure embedding problem is one example of the need to >>>> customize the syntax and behavior, but this extensibility will >>>> become even more important for supporting the idea of moving the >>>> documentation inside the image. For example, the ability to refer >>>> to a class, method or other artifacts will be quite relevant soon >>>> especially that the editor will be able to embed advanced elements >>>> inside the text. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>>> >>>>> Hi Stef - I think yourâs is a fair requirement (in fact I hit >>>>> something similar when doing a static website using a JS markdown >>>>> framework - and this is why I mentioned Kramdown which adds a few >>>>> extras to regular markdown - but it feels like it goes a bit too far). >>>>> >>>>> My next item on my learning todo list was to try and replace that >>>>> JS generator with something from Smalltalk - so I think we can >>>>> possibly come up with something that ticks all the right boxes >>>>> (Iâd like to try anyway). >>>>> >>>>> Iâll keep working away on it and compare notes with you. I think >>>>> with Pillar, it was more that things like headers, bold and >>>>> italics are similar concepts but just use different characters - >>>>> so I keep typing the wrong thing and getting frustrated >>>>> particularly when we embrace Git and readme.md is in markdown. >>>>> >>>>> >>>>> Tim >>>>> >>>>>> On 13 Aug 2017, at 20:08, Stephane Ducasse >>>>>> <stepharo.self(a)gmail.com> wrote: >>>>>> >>>>>> Hi tim >>>>>> >>>>>> I personally do not care much about the syntax but I care about >>>>>> what I >>>>>> can do with it >>>>>> (ref, cite, ... ) >>>>>> I cannot write books in markdown because reference to figures!!!!!! >>>>>> were missing. >>>>>> >>>>>> And of course a parser because markdown is not really nice to parse >>>>>> and I will not write a parser because I have something else to do. I >>>>>> want to make pillar smaller, simpler, nicer. >>>>>> >>>>>> Now if someone come up with a parser that parse for REAL a markdown >>>>>> that can be extended with decent behavior (figure reference, section >>>>>> reference, cite) and can be extended because there are many things >>>>>> that can be nice to have (for example I want to be able to write the >>>>>> example below) and emit a PillarModel (AST) we can talk to have >>>>>> another syntax for Pillar but not before. >>>>>> >>>>>> [[[test >>>>>> 2+3 >>>>>>>>> 5 >>>>>> ]]] >>>>>> >>>>>> and being able to verify that the doc is in sync. >>>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon >>>>>> <tim(a)testit.works> wrote: >>>>>>> Of course, I/we recognise and appreciate all the work that's >>>>>>> gone into docs in pillar - but I think it should be reasonably >>>>>>> straightforward to write a converter as it is pretty closely >>>>>>> related from what I have seen. >>>>>>> >>>>>>> So I don't make the suggestion flippantly, and would want to >>>>>>> help write a converter and get us to a common ground where we >>>>>>> can differentiate on the aspects where we can excel. >>>>>>> >>>>>>> Tim >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>>>> >>>>>>>> A long time issue with Markdown was that there was no >>>>>>>> standardization (and when I used Pillar's MD export ~2 years >>>>>>>> ago it didn't work well). >>>>>>>> >>>>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has >>>>>>>> become the de-facto standard, so it would make sense to support >>>>>>>> it bidirectionally with Pillar. >>>>>>>> >>>>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>>>> Well, technically it is just a CommonMark, as I am not using >>>>>>>> any github extensions. >>>>>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>> >>>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> âLive like you mean it." >>>> >>>> >>> >>> >> >

Aug. 15, 2017

[ANN] VistaCursor now scalable

by Torsten Bergmann

Hi, Mike Davis asked about changing the cursor size as he runs Pharo with Windows 10 on a Microsoft Surface @ 2736 x 1824 dpi. He discussed on Discord and said that all of the display is well scaled, except the mouse cursor which is too small for him. As the Windows VM supports larger cursors I added some support to my loadable goodie package "VistaCursor" now. So there is now a new setting to scale the provided cursors (see screenshots). Either freshly load the package from catalog or update to "VistaCursors-TorstenBergmann.5" if you want to check this out. This might be also be useful for presentations. Have fun T.

Aug. 14, 2017

← Newer
1
...
54
55
56
57
58
59
60
...
84
Older →

Jump to page: