- Pharo-users - lists.pharo.org

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

by Tim Mackinnon

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). 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â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 <mailto:dionisiydk@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 <mailto:tim@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 <https://gitlab.com/macta/PharoLambda> > And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E <https://www.youtube.com/watch?v=bNNCT1hLA3E> > > Tim > > >> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works <mailto:tim@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 <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 > > >

Aug. 14, 2017

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

by Tudor Girba

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. 14, 2017

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

by Tim Mackinnon

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 >>> >> >> >

Aug. 14, 2017

Re: [Pharo-users] Probably a bug in Garage SQLite

by Herby VojÄÃk

Stephane Ducasse wrote: > ah yes. > probably a missing rename during the migration to the new ffi. > > Stef Unfortunately there's more: 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: MessageNotUnderstood(Exception)>>signal ExternalData(Object)>>doesNotUnderstand: #pointerAt: FFIExternalArray class>>fromPointer:type:size: GASqlite3FFI>>blobFrom:at: GASqlite3Statement>>byteArrayAt: GASqlite3Statement>>valueOfColumn: GASqlite3ResultSet>>next GASqlite3ResultSet>>rows GAGlorpDriver>>basicExecuteSQLString: PharoDatabaseAccessor>>basicExecuteSQLString: PharoDatabaseAccessor>>executeCommandUnbound: [..snip..] Now ExternalData does not understand #pointerAt: (only ByteArray and FFIExternalStructureReferenceHandle do, don't know how to fix this quickly... :-( ) Herby > > On Sun, Aug 13, 2017 at 9:04 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >> Stephane Ducasse wrote: >>> Do you have the same bug in 5.0? >>> Because I do not know if garage was really tested on 60. >> >> Don't know (don't have it), but last commit in Garage-SQLite >> GuillermoPolito.26 from 2016. The mentioned #nbBindingOf: is sent at no >> place at all in the image (except supersend in the lone method itself), so >> it definitely looks like it need to rename to ffiBindingOf: for 60. >> >> Herby >> >> >>> Stef >>> >>> On Sun, Aug 13, 2017 at 8:41 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>>> Stephane Ducasse wrote: >>>>> Hi Herby >>>>> >>>>> On which version of Pharo are you trying? Because lot of changes >>>>> happened on Pharo 60 FFI. >>>>> >>>>> Stef >>>>> >>>>> On Sun, Aug 13, 2017 at 6:11 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>>>>> Hello! >>>>>> >>>>>> This testing code: >>>>>> >>>>>> | databaseFile login accessor sqlString | >>>>>> databaseFile := Smalltalk imageDirectory asFileReference / >>>>>> 'play.sqlite'. >>>>>> login := Login new >>>>>> database: SQLite3Platform new; >>>>>> host: ''; >>>>>> port: ''; >>>>>> username: ''; >>>>>> password: ''; >>>>>> databaseName: databaseFile fullPath asZnUrl >>>>>> asString; >>>>>> yourself. >>>>>> accessor := DatabaseAccessor forLogin: login. >>>>>> accessor login. >>>>>> sqlString := 'SELECT * FROM AGENT'. >>>>>> (accessor basicExecuteSQLString: sqlString) contents inspect. >>>>>> >>>>>> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project >>>> >>>> As I wrote here, Pharo 6.1. >>>> >>>> >>>>>> dependency) with: >>>>>> >>>>>> Error: Unable to resolve external type: sqlite3 >>>>>> >>>>>> FFICallout(Object)>>error: >>>>>> FFICallout>>resolveType: >>>>>> FFICallout>>typeName:pointerArity: >>>>>> FFICallout>>argName:indirectIndex:type:ptrArity: >>>>>> FFIFunctionParser>>parseArgument >>>>>> FFIFunctionParser>>parseArguments >>>>>> FFIFunctionParser>>parseNamedFunction: >>>>>> FFICalloutMethodBuilder>>parseSignature: >>>>>> FFICalloutMethodBuilder>>generate >>>>>> FFICalloutMethodBuilder>>build: >>>>>> FFICalloutAPI>>function:module: >>>>>> GASqlite3FFI(Object)>>ffiCall:module: >>>>>> GASqlite3FFI>>apiErrorMessage: >>>>>> GASqlite3FFI>>signal:with:on: >>>>>> GASqlite3FFI>>checkForOk:on: >>>>>> GASqlite3FFI>>prepare:on:with: >>>>>> GASqlite3Statement>>prepare >>>>>> GASqlite3Driver>>prepare: >>>>>> GASqlite3ResultSet>>prepareStatement: >>>>>> GASqlite3ResultSet>>execute:withCollection: >>>>>> GASqlite3ResultSet>>execute:with:on: >>>>>> GASqlite3Driver>>execute:with: >>>>>> GASqlite3Driver>>execute: >>>>>> GAGlorpDriver>>basicExecuteSQLString: >>>>>> PharoDatabaseAccessor>>basicExecuteSQLString: >>>>>> UndefinedObject>>DoIt >>>>>> OpalCompiler>>evaluate >>>>>> [..snip..] >>>>>> >>>>>> Problem seems to be that in FFICallout>> resolveType:, the line >>>>>> >>>>>> binding := resolver ffiBindingOf: name asSymbol. >>>>>> >>>>>> actually produces nil, resolver being GASqlite3FFI class. If looking at >>>>>> the >>>>>> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is >>>>>> >>>>>> nbBindingOf: aTypeName >>>>>> ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: >>>>>> aTypeName >>>>>> ] >>>>>> >>>>>> though. If I copy near-mindlessly and add: >>>>>> >>>>>> ffiBindingOf: aTypeName >>>>>> ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: >>>>>> aTypeName ] >>>>>> >>>>>> then the code above fails correctly with: 'no such table: AGENT'. >>>>>> >>>>>> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite >>>>>> driver? >>>>>> >>>>>> Herby >>>> >> >

Aug. 13, 2017

Re: [Pharo-users] Probably a bug in Garage SQLite

by Stephane Ducasse

ah yes. probably a missing rename during the migration to the new ffi. Stef On Sun, Aug 13, 2017 at 9:04 PM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Stephane Ducasse wrote: >> >> Do you have the same bug in 5.0? >> Because I do not know if garage was really tested on 60. > > > Don't know (don't have it), but last commit in Garage-SQLite > GuillermoPolito.26 from 2016. The mentioned #nbBindingOf: is sent at no > place at all in the image (except supersend in the lone method itself), so > it definitely looks like it need to rename to ffiBindingOf: for 60. > > Herby > > >> >> Stef >> >> On Sun, Aug 13, 2017 at 8:41 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>> >>> Stephane Ducasse wrote: >>>> >>>> Hi Herby >>>> >>>> On which version of Pharo are you trying? Because lot of changes >>>> happened on Pharo 60 FFI. >>>> >>>> Stef >>>> >>>> On Sun, Aug 13, 2017 at 6:11 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>>>> >>>>> Hello! >>>>> >>>>> This testing code: >>>>> >>>>> | databaseFile login accessor sqlString | >>>>> databaseFile := Smalltalk imageDirectory asFileReference / >>>>> 'play.sqlite'. >>>>> login := Login new >>>>> database: SQLite3Platform new; >>>>> host: ''; >>>>> port: ''; >>>>> username: ''; >>>>> password: ''; >>>>> databaseName: databaseFile fullPath asZnUrl >>>>> asString; >>>>> yourself. >>>>> accessor := DatabaseAccessor forLogin: login. >>>>> accessor login. >>>>> sqlString := 'SELECT * FROM AGENT'. >>>>> (accessor basicExecuteSQLString: sqlString) contents inspect. >>>>> >>>>> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project >>> >>> >>> As I wrote here, Pharo 6.1. >>> >>> >>>>> dependency) with: >>>>> >>>>> Error: Unable to resolve external type: sqlite3 >>>>> >>>>> FFICallout(Object)>>error: >>>>> FFICallout>>resolveType: >>>>> FFICallout>>typeName:pointerArity: >>>>> FFICallout>>argName:indirectIndex:type:ptrArity: >>>>> FFIFunctionParser>>parseArgument >>>>> FFIFunctionParser>>parseArguments >>>>> FFIFunctionParser>>parseNamedFunction: >>>>> FFICalloutMethodBuilder>>parseSignature: >>>>> FFICalloutMethodBuilder>>generate >>>>> FFICalloutMethodBuilder>>build: >>>>> FFICalloutAPI>>function:module: >>>>> GASqlite3FFI(Object)>>ffiCall:module: >>>>> GASqlite3FFI>>apiErrorMessage: >>>>> GASqlite3FFI>>signal:with:on: >>>>> GASqlite3FFI>>checkForOk:on: >>>>> GASqlite3FFI>>prepare:on:with: >>>>> GASqlite3Statement>>prepare >>>>> GASqlite3Driver>>prepare: >>>>> GASqlite3ResultSet>>prepareStatement: >>>>> GASqlite3ResultSet>>execute:withCollection: >>>>> GASqlite3ResultSet>>execute:with:on: >>>>> GASqlite3Driver>>execute:with: >>>>> GASqlite3Driver>>execute: >>>>> GAGlorpDriver>>basicExecuteSQLString: >>>>> PharoDatabaseAccessor>>basicExecuteSQLString: >>>>> UndefinedObject>>DoIt >>>>> OpalCompiler>>evaluate >>>>> [..snip..] >>>>> >>>>> Problem seems to be that in FFICallout>> resolveType:, the line >>>>> >>>>> binding := resolver ffiBindingOf: name asSymbol. >>>>> >>>>> actually produces nil, resolver being GASqlite3FFI class. If looking at >>>>> the >>>>> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is >>>>> >>>>> nbBindingOf: aTypeName >>>>> ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: >>>>> aTypeName >>>>> ] >>>>> >>>>> though. If I copy near-mindlessly and add: >>>>> >>>>> ffiBindingOf: aTypeName >>>>> ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: >>>>> aTypeName ] >>>>> >>>>> then the code above fails correctly with: 'no such table: AGENT'. >>>>> >>>>> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite >>>>> driver? >>>>> >>>>> Herby >>> >>> >> > >

Aug. 13, 2017

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

by Stephane Ducasse

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 >> > >

Aug. 13, 2017

Re: [Pharo-users] pharo config problem

by Johannes Brauer

Hi Stef, the connection from a Monticello Browser in a local image with same username and password works fine. Johannes > Am 13.08.2017 um 20:34 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi johannes > > I do not know how to help you but this is strange. > We managed our synectique private code on STHub and it works. > Now STHub is getting stranger and stranger. So may be your passwrd got desync. > Esteban? if you read this mail. Can you check when you are back from vacation? > > Stef > > On Sun, Aug 13, 2017 at 7:20 PM, jb <brauer(a)nordakademie.de> wrote: >> Hi, >> >> I have a problem with connection to a private smalltalkhub rep from the >> command line with pharo config. >> I think I set the --username and --password options correctly, but I always >> get: >> ZnHttpUnsuccessful: 403 Forbidded >> >> If I make the rep public then there is no access problem. >> >> Any hints what is going wrong? >> >> Johannes >> >> >> >> -- >> View this message in context: http://forum.world.st/pharo-config-problem-tp4960715.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >

Aug. 13, 2017

Re: [Pharo-users] Probably a bug in Garage SQLite

by Herby VojÄÃk

Stephane Ducasse wrote: > Do you have the same bug in 5.0? > Because I do not know if garage was really tested on 60. Don't know (don't have it), but last commit in Garage-SQLite GuillermoPolito.26 from 2016. The mentioned #nbBindingOf: is sent at no place at all in the image (except supersend in the lone method itself), so it definitely looks like it need to rename to ffiBindingOf: for 60. Herby > > Stef > > On Sun, Aug 13, 2017 at 8:41 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >> Stephane Ducasse wrote: >>> Hi Herby >>> >>> On which version of Pharo are you trying? Because lot of changes >>> happened on Pharo 60 FFI. >>> >>> Stef >>> >>> On Sun, Aug 13, 2017 at 6:11 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>>> Hello! >>>> >>>> This testing code: >>>> >>>> | databaseFile login accessor sqlString | >>>> databaseFile := Smalltalk imageDirectory asFileReference / >>>> 'play.sqlite'. >>>> login := Login new >>>> database: SQLite3Platform new; >>>> host: ''; >>>> port: ''; >>>> username: ''; >>>> password: ''; >>>> databaseName: databaseFile fullPath asZnUrl >>>> asString; >>>> yourself. >>>> accessor := DatabaseAccessor forLogin: login. >>>> accessor login. >>>> sqlString := 'SELECT * FROM AGENT'. >>>> (accessor basicExecuteSQLString: sqlString) contents inspect. >>>> >>>> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project >> >> As I wrote here, Pharo 6.1. >> >> >>>> dependency) with: >>>> >>>> Error: Unable to resolve external type: sqlite3 >>>> >>>> FFICallout(Object)>>error: >>>> FFICallout>>resolveType: >>>> FFICallout>>typeName:pointerArity: >>>> FFICallout>>argName:indirectIndex:type:ptrArity: >>>> FFIFunctionParser>>parseArgument >>>> FFIFunctionParser>>parseArguments >>>> FFIFunctionParser>>parseNamedFunction: >>>> FFICalloutMethodBuilder>>parseSignature: >>>> FFICalloutMethodBuilder>>generate >>>> FFICalloutMethodBuilder>>build: >>>> FFICalloutAPI>>function:module: >>>> GASqlite3FFI(Object)>>ffiCall:module: >>>> GASqlite3FFI>>apiErrorMessage: >>>> GASqlite3FFI>>signal:with:on: >>>> GASqlite3FFI>>checkForOk:on: >>>> GASqlite3FFI>>prepare:on:with: >>>> GASqlite3Statement>>prepare >>>> GASqlite3Driver>>prepare: >>>> GASqlite3ResultSet>>prepareStatement: >>>> GASqlite3ResultSet>>execute:withCollection: >>>> GASqlite3ResultSet>>execute:with:on: >>>> GASqlite3Driver>>execute:with: >>>> GASqlite3Driver>>execute: >>>> GAGlorpDriver>>basicExecuteSQLString: >>>> PharoDatabaseAccessor>>basicExecuteSQLString: >>>> UndefinedObject>>DoIt >>>> OpalCompiler>>evaluate >>>> [..snip..] >>>> >>>> Problem seems to be that in FFICallout>> resolveType:, the line >>>> >>>> binding := resolver ffiBindingOf: name asSymbol. >>>> >>>> actually produces nil, resolver being GASqlite3FFI class. If looking at >>>> the >>>> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is >>>> >>>> nbBindingOf: aTypeName >>>> ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName >>>> ] >>>> >>>> though. If I copy near-mindlessly and add: >>>> >>>> ffiBindingOf: aTypeName >>>> ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: >>>> aTypeName ] >>>> >>>> then the code above fails correctly with: 'no such table: AGENT'. >>>> >>>> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite >>>> driver? >>>> >>>> Herby >> >

Aug. 13, 2017

Re: [Pharo-users] Probably a bug in Garage SQLite

by Stephane Ducasse

Do you have the same bug in 5.0? Because I do not know if garage was really tested on 60. Stef On Sun, Aug 13, 2017 at 8:41 PM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Stephane Ducasse wrote: >> >> Hi Herby >> >> On which version of Pharo are you trying? Because lot of changes >> happened on Pharo 60 FFI. >> >> Stef >> >> On Sun, Aug 13, 2017 at 6:11 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>> >>> Hello! >>> >>> This testing code: >>> >>> | databaseFile login accessor sqlString | >>> databaseFile := Smalltalk imageDirectory asFileReference / >>> 'play.sqlite'. >>> login := Login new >>> database: SQLite3Platform new; >>> host: ''; >>> port: ''; >>> username: ''; >>> password: ''; >>> databaseName: databaseFile fullPath asZnUrl >>> asString; >>> yourself. >>> accessor := DatabaseAccessor forLogin: login. >>> accessor login. >>> sqlString := 'SELECT * FROM AGENT'. >>> (accessor basicExecuteSQLString: sqlString) contents inspect. >>> >>> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project > > > As I wrote here, Pharo 6.1. > > >>> dependency) with: >>> >>> Error: Unable to resolve external type: sqlite3 >>> >>> FFICallout(Object)>>error: >>> FFICallout>>resolveType: >>> FFICallout>>typeName:pointerArity: >>> FFICallout>>argName:indirectIndex:type:ptrArity: >>> FFIFunctionParser>>parseArgument >>> FFIFunctionParser>>parseArguments >>> FFIFunctionParser>>parseNamedFunction: >>> FFICalloutMethodBuilder>>parseSignature: >>> FFICalloutMethodBuilder>>generate >>> FFICalloutMethodBuilder>>build: >>> FFICalloutAPI>>function:module: >>> GASqlite3FFI(Object)>>ffiCall:module: >>> GASqlite3FFI>>apiErrorMessage: >>> GASqlite3FFI>>signal:with:on: >>> GASqlite3FFI>>checkForOk:on: >>> GASqlite3FFI>>prepare:on:with: >>> GASqlite3Statement>>prepare >>> GASqlite3Driver>>prepare: >>> GASqlite3ResultSet>>prepareStatement: >>> GASqlite3ResultSet>>execute:withCollection: >>> GASqlite3ResultSet>>execute:with:on: >>> GASqlite3Driver>>execute:with: >>> GASqlite3Driver>>execute: >>> GAGlorpDriver>>basicExecuteSQLString: >>> PharoDatabaseAccessor>>basicExecuteSQLString: >>> UndefinedObject>>DoIt >>> OpalCompiler>>evaluate >>> [..snip..] >>> >>> Problem seems to be that in FFICallout>> resolveType:, the line >>> >>> binding := resolver ffiBindingOf: name asSymbol. >>> >>> actually produces nil, resolver being GASqlite3FFI class. If looking at >>> the >>> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is >>> >>> nbBindingOf: aTypeName >>> ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName >>> ] >>> >>> though. If I copy near-mindlessly and add: >>> >>> ffiBindingOf: aTypeName >>> ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: >>> aTypeName ] >>> >>> then the code above fails correctly with: 'no such table: AGENT'. >>> >>> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite >>> driver? >>> >>> Herby > >

Aug. 13, 2017

Re: [Pharo-users] Probably a bug in Garage SQLite

by Herby VojÄÃk

Stephane Ducasse wrote: > Hi Herby > > On which version of Pharo are you trying? Because lot of changes > happened on Pharo 60 FFI. > > Stef > > On Sun, Aug 13, 2017 at 6:11 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >> Hello! >> >> This testing code: >> >> | databaseFile login accessor sqlString | >> databaseFile := Smalltalk imageDirectory asFileReference / >> 'play.sqlite'. >> login := Login new >> database: SQLite3Platform new; >> host: ''; >> port: ''; >> username: ''; >> password: ''; >> databaseName: databaseFile fullPath asZnUrl >> asString; >> yourself. >> accessor := DatabaseAccessor forLogin: login. >> accessor login. >> sqlString := 'SELECT * FROM AGENT'. >> (accessor basicExecuteSQLString: sqlString) contents inspect. >> >> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project As I wrote here, Pharo 6.1. >> dependency) with: >> >> Error: Unable to resolve external type: sqlite3 >> >> FFICallout(Object)>>error: >> FFICallout>>resolveType: >> FFICallout>>typeName:pointerArity: >> FFICallout>>argName:indirectIndex:type:ptrArity: >> FFIFunctionParser>>parseArgument >> FFIFunctionParser>>parseArguments >> FFIFunctionParser>>parseNamedFunction: >> FFICalloutMethodBuilder>>parseSignature: >> FFICalloutMethodBuilder>>generate >> FFICalloutMethodBuilder>>build: >> FFICalloutAPI>>function:module: >> GASqlite3FFI(Object)>>ffiCall:module: >> GASqlite3FFI>>apiErrorMessage: >> GASqlite3FFI>>signal:with:on: >> GASqlite3FFI>>checkForOk:on: >> GASqlite3FFI>>prepare:on:with: >> GASqlite3Statement>>prepare >> GASqlite3Driver>>prepare: >> GASqlite3ResultSet>>prepareStatement: >> GASqlite3ResultSet>>execute:withCollection: >> GASqlite3ResultSet>>execute:with:on: >> GASqlite3Driver>>execute:with: >> GASqlite3Driver>>execute: >> GAGlorpDriver>>basicExecuteSQLString: >> PharoDatabaseAccessor>>basicExecuteSQLString: >> UndefinedObject>>DoIt >> OpalCompiler>>evaluate >> [..snip..] >> >> Problem seems to be that in FFICallout>> resolveType:, the line >> >> binding := resolver ffiBindingOf: name asSymbol. >> >> actually produces nil, resolver being GASqlite3FFI class. If looking at the >> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is >> >> nbBindingOf: aTypeName >> ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName ] >> >> though. If I copy near-mindlessly and add: >> >> ffiBindingOf: aTypeName >> ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: aTypeName ] >> >> then the code above fails correctly with: 'no such table: AGENT'. >> >> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite >> driver? >> >> Herby

Aug. 13, 2017