[04:03:25] [connected at Thu Oct 30 04:03:25 2003] [04:03:25] <> *** Looking up your hostname... [04:03:26] <> *** Checking ident [04:03:26] <> *** Found your hostname [04:03:56] <> *** No identd (auth) response [04:03:56] <> *** Your host is sterling.freenode.net[freebsd.widexs.nl/6667], running version dancer-ircd-1.0.32 [04:03:56] [I have joined #peak] [04:03:56] ** sterling.freenode.net set the topic to PEAK http://peak.telecommunity.com || WikiPages at http://peak.telecommunity.com/DevCenter || IRC-Logs: http://peak.telecommunity.com/irc-logs/ [04:19:24] ** todobot has joined us [04:20:19] ** todobot has joined us [04:20:20] ** todobot_ has joined us [04:20:23] ** todobot__ has joined us [04:20:35] ** todobot has joined us [04:20:35] ** todobot_ has joined us [04:20:38] ** todobot__ has joined us [04:30:30] ** radekk has joined us [07:29:00] ** dlk has joined us [08:17:56] ** vlado has joined us [08:19:52] anyone alive ? [09:02:36] ** jack-e has joined us [09:35:52] hey radek .. haven't seen you for a while .. [09:40:18] hi, I had another things to do. I am back now. [09:40:28] welcome back :) [09:42:22] Even I didn't catch interesting stuff about generating SQL queries from some formal model. [09:43:22] looks promising .. yes [09:43:35] I am working now on entity DM that is able automaticaly generate CREATE/INSERT/UPDATE/DELETE commands from model.Element. [09:45:03] Some design problems occured. There are five entities in this system: SQL connection, data manager, model element, feature and finally data type. [09:45:39] ok [09:46:06] i'm working on a model.Element -> GuiSchema/GuiGenerator (wxPython) [09:46:49] what problems did you run into ? [09:47:49] I need some adaptors, decorators or glue that allows present importatnt informations to various part of this system. Current source code seems too complicated. [09:48:29] For example data manager must find SQL data types and SQL column names for given feature. [09:50:20] jack-e: what is intention of your convertor? [09:51:03] jack-e: generating gui from model.Element? [09:51:05] generating gui-forms from model.Element classes on the fly [09:51:06] jep [09:51:46] i adapt a ITypeInfo to e.g. ITextWidget to get adapters for value-conversion and field-type-info [09:51:55] (basically a gui-schema) [09:52:42] and then the nllgui.wxgui.generator.ComponentGenerator creates ComponentsSpecs (tree of data, could also be xml) that are [09:52:44] jack-e: It would be interesting to make model.Element -> HTML form or web widget [09:53:06] used to build up the actual gui-objects [09:54:13] i haven't yet played with DOMlets .. but iirc pje and roche had a fairly long thread about that on the list [09:54:27] jack-e: I think that problem is rather similar. We have model.Element with features with data types. I adapt this to SQL and you to widgets. [09:54:35] right [09:54:47] (that's why i mentioned it :) [09:54:56] jack-e: do you have this convertor in CVS? I ma just currious about design. [09:55:10] you can look at it at cvs.net-labs.de -> /libs/nllgui/src/nllgui/ [09:55:26] guischema.py is the model.Element -> Abstract Schemainfo part [09:56:46] wxgui/valuelink.py is a Protocol for retrieving the model.Elements data in a uniform way (struct of structs of serialized data) that could be sent through the wire with some messaging system (work in progress) [09:57:16] i adapt model.Element to the ValueLink protocol and i adapt the GuiComponents to the IValueLink protocol [09:57:40] then the 2 adapters exchange information via a1.setValue(a2.getValue()) or the other way round [09:58:01] wxgui/generator.py is the component-generator that creates the wxpython gui [10:04:37] jack-e: looking in source I am not able to quickly understand system architecture. My GUI programming skills are poor. [10:04:54] what file are you looking at ? [10:05:56] jack-e: You have talked about ValueLink protocol so I am studying valuelink.py [10:07:37] these are basically just adapters, that handle the differences between a e.g. .data or .checked [10:08:07] and in ../guischema.py there is the model.Element related parts [10:08:52] the adapters in valuelink.py would also care about value-conversion (or at least look them up somehow) to meet the "requirements" of the IWidget they are created for [10:10:14] the valuelink protocol currently represents the model.Element's data (incl. composite-objectrefs) in a peak.util.structs that contain data or structs again [10:10:29] with that you can create multi-element forms [10:10:39] why name ValueLink? I think that "grep advise *" and "grep adapt *" helps to find interesting points in source. [10:10:42] and transfer the data correctly in between [10:11:03] i didn't think of another name .. [10:11:15] Exchange is so overused i thkn [10:11:44] and it descibes what i want .. it is just used to link the data from the model.Element to the data in the GuiComponents [10:12:38] DataLink would perhaps been better .. but that is just a name .. don't care to much about that yet .. it's all in very basic state and the concept is currently more important than the concrete naming [10:13:09] I see. You are able to link Element instance with particular form widget and fill entries with element data. [10:13:18] yes [10:13:24] that's one part [10:13:35] and the other is to generate the gui from the model.Element [10:14:32] background is, that the gui-side doesn't know anything about the model.Element side and the other way round .. so it is reusable and extenisble i think [10:15:50] gui uses information only from ValueLink adapter so it doesn't know about element. [10:16:12] i invented the gui-schema, that is created from the model.Element information [10:16:40] that should be representable as xml so remote clients can create gui/exchange data without having access to the actual instance [10:17:39] a generic peak.schema thing would be a good thing i think (with some configurable-metadata for special needs) [10:18:06] it would be somehow a duplication of the model.Element Information [10:19:21] isn't some things in peak.metamodels? [10:19:44] that would be an option as well .. to use the uml-information .. [10:20:24] i used storage.xmi to load a UML-Model into an app and displayed the data with a tree and autogenerated forms [10:20:44] cvs.net-labs.de -> libs/nllsandbox/gui-components/umlexplorer [10:22:46] it just for playing around with the gui stuff [10:43:46] It gets me one day to understand my peak code after three week pause :-( [10:44:24] that's bad [10:45:45] i really try to use specific, long names for methods and attributes, to make the code as readable as possible .. but sometimes this just doesn't work .. [10:46:35] (and the python/zope3 styleguide help there too) [10:46:45] One forgets too quickly after 30 :-) [10:47:04] how much over 30 ? (me ==30) :) [10:47:28] four months to 33 [10:47:53] ok .. is it really going downward that fast in the next 2 years ??? ;-P [10:48:36] yes, believe me. Knees ache etc... [10:48:40] hehe [10:50:24] i'm curently switching weekly between my GuiFramework and the Stateful Workflow Implementation (that keeps your brain young) .. [10:51:14] i have noticed workflow in your CVS. It will be next thing for me to do. [10:51:37] i refactored the statefull process last week [10:52:42] it uses now a nearly the same spec as Uml StateChartDiagram (when my uml-tool can export StateCharts to XMI i probably will swich to xmi instead of the proprietary format now) [10:53:06] it can handle composite-states but not yet Concurrent [10:55:43] i cannot find file with my notes about workflow :-) Have you know about http://www.wfmc.org/standards/standards.htm ? [10:56:18] i have implemented the wfmc-spec about 1.5 years ago with Transwarp [10:56:44] i already started to model the Definition-Elements for current peak .. but i haven't yet had any time to get this part further [10:57:08] to many unfinished projects currently :) [10:57:19] me too [11:01:37] jack-e is now known as jack-e|brb [11:15:39] jack-e|brb is now known as jack-e [11:15:48] /msg NickServ IDENTIFY goldie [11:16:01] ups [11:46:05] ** pje has joined us [11:46:13] Howdy. [11:46:19] hi phillip [11:46:49] how are things going ?? [11:47:03] Not bad. [11:47:13] Been a bit busy with non-PEAK work... [11:47:19] porting an app from Sybase to Oracle. [11:47:30] Not that you can't probably tell that by the recent commits. :) [11:47:31] doesn't sound like fun .. [11:47:46] hehe [11:47:50] No, but in the process I'm improving PEAK so that this will be a one-time pain. [11:48:00] ok [11:48:20] The next thing I plan to do is add an SQLConnection "thunk" mechanism to provide general DB-specific mappings [11:49:31] what do you mean by db-specifc mappings ? [11:49:31] Of either functions, or constants, or whatever sort of configuration you might want. [11:49:44] things like paramStyle or types .. [11:49:50] Say you have some function that's database-specific as to how it's implemented... [11:50:01] Like, I have some date manipulation functions in Sybase... [11:50:09] ok [11:50:20] But Oracle has totally different date functions. [11:50:35] So, the idea is that I'd have a property namespace that's driver-specific. [11:50:44] And accessible via the SQLConnection object. [11:50:59] i saw that .. you started work on that already in cvs ? [11:51:15] So I might bind to 'db/thunks/MyDateFuncion' to get the right function for the current DB. [11:51:19] No... [11:51:30] what's in CVS is just custom type maps... [11:51:33] you made the type-converters driverspecific [11:51:42] But it gave me the idea that I could do other driver-specific things. [11:51:46] right [11:52:04] I'd want to put the thunks in a different namespace, though, because the typemap namespace can be really *weird* for some drivers. [11:52:11] (E.g. DCOracle2) [11:52:41] sounds good [11:52:45] I think the new mechanism needs a better name than "thunks" though. [11:52:50] yup [11:53:10] I also think it'd be cool to "preload" the namespace with mappings for all the JDBC standard functions. [11:53:31] i don't know jdbc at all [11:53:41] what do they provide ? [11:53:58] Standardized names for functions, across any backend that supports the function. [11:54:17] (SQL functions) [11:54:21] ok [11:54:45] So, with that plus the new type mapping, you'd almost be able to write cross-platform SQL. [11:55:13] Really, the missing bit at that point would be to have a standardized paramstyle. [11:55:48] I'm almost tempted to write a paramstyle standardization feature, but I don't need/want it for my current project. [11:56:32] i'm currenty not using the sql-stuff -- i still have not finished my GUI that could use all the information from the DB :) [11:56:37] The project runs on an older framework I built about 5 years ago called ASDF. I just patched its DB drivers to call down to a PEAK connection object, but it doesn't do parameters at all. [11:57:06] Hmmm. [11:57:41] Now that I think of it, I probably shouldn't bother standardizing paramstyles, or worry about how to convert functions inline. [11:58:19] Since I just wrote a relational algebra package that's completely backend independent anyway. I should just plan in future to generate SQL from it, and use the thunk mechanism to map functions. [11:59:07] And once the conceptual query mechanism is built, I can probably forget about SQL altogether. :) [11:59:35] how would the resulting SQL-string "use" the mapped functions .. i do not yet get the relation of those to. [11:59:53] or does the sql-generation process already invoke them ? [12:01:17] Well, the current SQL generation process involves abstract function objects, and the SQL-generation driver can interpret them any way it likes. [12:01:26] So far, that's just an abstract mechanism, though. [12:01:29] ok [12:02:06] In practice, I expect that SQL" functions" will probably be configuration keys exported from some module. [12:02:43] When you use them in a query, they'll just be a symbol. The driver will convert it to a real expression string using the thunks. [12:03:32] So, you'd probably make some kind of query like SomeTable(where=SomeFunc(SomeTable['someCol']).gt(42)) [12:03:50] To retrieve all rows where SomeFunc(someCol) > 42 [12:05:44] Of course, I hope to be able to wrap that sort of thing into a conceptual-level query, that isn't tables/columns but objects/attributes. [12:06:07] And that will require a schema mapping mechanism, whose nature is as yet unknown [12:07:02] we talked about schema before .. [12:07:15] Hm? [12:07:48] radekk is working on some system that creates sql-tables from model.Element iirc [12:08:13] Ah. [12:08:22] and i use the model.Element information for creating GUI-Forms .. [12:08:52] I'm not concerned about creating, myself. I need to be able to specify mappings from arbitrary object schemas to existing DB schemas. [12:09:16] So my work will be emphasizing lookup of mapping info. [12:10:24] i have a question whether to use a NameContext or an AddressContext: [12:10:38] i'm trying to write a naming-context for SLP (Service Location Protocol) [12:11:13] urls look like: "service:abstractServiceType:ConcreteServiceType://url;para1=val2" [12:11:31] when i do a naming.lookup(ctx, "service:") [12:11:52] i get a serviceContext that allows me to iterate over all serviceTypes that are registered [12:12:12] i used a NameContext for this .. is this correct .. or what is the difference between those two [12:12:13] ? [12:14:20] Hm. [12:14:34] Look at the Wiki page on naming systems... [12:14:45] Is it a name or an address? [12:14:59] An address is fixed... *anybody* could go to that address and in principle get the same thing. [12:15:10] A name's interpretation requires a naming service to map to an address. [12:15:40] The distinction isn't based on whether locations are iterable. [12:15:53] Does that make sense? [12:15:55] hmm .. [12:16:51] so a serviceType is basically a characteristica of the "concreteServiceType://url..." [12:17:25] that you can query for "service:cups-printers.postscript:" [12:17:40] that would give a ServiceTypeContext [12:18:12] "service:cups-printers.postscript:cups://somehost:631/printers/office" would give back a ServiceInfo object [12:18:58] you can then create a connection-object of a property type by calling si.getService() or something like that [12:19:22] if i have understood the naming system correctly that latter is an address [12:19:42] because it points to exactly one object and is (as long as it lives) unique [12:19:48] right ? [12:20:46] I'm a little confused. [12:21:07] SLP defines a repository where services can be registered [12:21:14] they are classified by serviceTypes [12:21:28] Okay, so it's a *naming* service, then, right? [12:21:41] yes [12:21:42] You ask it for something by name, and it gives you an address? [12:22:04] The part that's confusing me is that you've got what looks like an address in there. [12:22:23] you ask for services of type "cups-printers" and you get a list of service-info objects that carry information how to reach the service [12:22:38] I mean, if you have the 'cups://somehost...' part, why do you need to look in the SLP? [12:23:01] SLP also manages attributes for its entries [12:23:02] But the service-info objects only have addresses, not persistent names? [12:23:24] so you can query for "cups-printers" that are on "floor=basement" [12:23:32] Ah. [12:23:57] I'm afraid that I never got as far as adding search capability to peak.naming's interfaces. [12:24:26] So individual services don't have names? [12:24:27] i wanted to implement them directly in the ServiceContext/ServiceTypeContext object for now [12:24:50] no .. they are referenced by their service-url [12:25:25] Odd. [12:25:59] it somehow makes sense .. there can only be one service "cups://my.host:631/printers/office" [12:26:14] If I was doing this, I'd make it a name service... and have the name+query give back an object representing a collection of services. [12:26:14] i need to get a friend to the train .. i'm back in 5 mins [12:26:35] jack-e is now known as jack-e|brb [12:26:36] That's true but what's the point in having the lookup service if you have to have the address already? ;) [12:35:42] jack-e|brb is now known as jack-e [12:35:45] * jack-e is back [12:36:27] that's true [12:37:37] so it would better solved with a DataManager than a NamingContext you think ? [12:37:57] No... it's a naming service. It's just a rather odd one. :) [12:38:02] hehe [12:38:36] Its primary value is in enumerating the contents of a context, rather than retrieving an individual item. [12:39:03] So, it's really more a directory service than a naming service. I just haven't implemented the "directory" features of JNDI in peak.naming at present. [12:39:23] yes .. it is made for autoconfigured environments where you need know nothing about [12:40:03] there is a JNDI binding for openslp that inspired me :) [12:41:54] Of course, nothing stops you from adding search methods to your context, it'll just be an "extension". [12:42:07] right .. that's what i wanted to do for now [12:42:24] You can subclass one of the context interfaces, and when you bind to it you can adapt to your interface, to make sure you're getting the right kind of context. [12:42:57] yep [12:58:31] Any thoughts on what I should call the thunk mechanism? [12:59:27] nope .. i'm a bad name-creator :) [12:59:50] Maybe instead of providing a generic thunk mechanism explicitly, I should just create specific thunks for functions, application config, etc. [12:59:58] Then it'll be more specific. [13:00:12] and then have different namespaces as well ? [13:00:22] ** Maniac has joined us [13:00:29] Yeah. [13:00:35] sounds good [13:00:55] Like 'someDB.functions', 'someDB.appConfig', etc. [13:01:15] yes .. much better than "thunk" [13:01:38] this sounds as it could be of use for other components as well .. [13:01:45] I'm probably going to still have a thunk class... maybe PropertyThunk. [13:02:04] Well, it only makes sense for components where there are multiple implementations of an interface. [13:02:18] Yet still having enough in common to only need a few thunks. [13:02:40] right [13:04:07] And then you'll bind to e.g. 'myDB/appConfig/something.I.need' [13:04:24] In order to get access to a backend-specific configuration value. [13:04:32] :) [13:05:16] Heck, I'm tempted to refactor typemaps to use the same mechanism. [13:11:03] Hmmm... [13:11:23] I wonder if I could implement this using the Fallback() class I just added? [13:11:33] It already knows a property namespace prefix. Hmm. [13:14:23] So I might then do 'appConfig = binding.Make(lambda: Fallback("someDb.appConfig"))' in a DB driver. [13:14:51] Fallback is starting to look like a lousy name for it, though. [13:16:36] Maybe I should just fold its behavior into PropertySet [13:17:50] But then I'd have to do it in a backward-incompatible way. [13:21:30] Or I could create a new type, and call it Namespace. 'config.Namespace("some.Property")' [13:21:41] And then deprecate PropertySet. [13:24:16] That sounds good. 'config.Namespace()' will treat getattr differently than PropertySet does, will use a differnet constructor, and will support both ISmartProperty and IAttachable. [13:24:50] That will let it be used as a namespace on a component, as a replacement for Fallback, and as a replacement for PropertySet. [13:30:23] a config.Namespace('my.app') would give back an NamespaceInstance that "traverses" __getattrs__ to the corresponding propertylookup ? [13:30:44] Yes... and if you getattr 'foo.bar' then you'd get my.app.foo.bar [13:30:59] looks good [13:31:02] So, you could use it in a component path, e.g. Obtain('ns/foo.bar') [13:31:23] Thus, it's a "thunk" into a property namespace from the component path namespace. [13:31:29] * pje is coding it up now [13:31:47] go for it .. i'll give my slp-context another try .. [13:31:53] PropertySet is sorta similar... but it doesn't do getattr that way... instead, it returns a new PropertySet for each getattr. [13:32:38] you would need to Obtain('ps/foo/bar') then ? [13:33:02] Yeah... and then you'd end up with a property set. [13:33:12] how would i get to its value ? [13:33:17] You'd have to then *call* it to get the value. [13:33:20] ok [13:33:37] So, it's not as useful, but I was thinking different use case when I wrote it. [13:33:49] It turns out I never wanted to use it that way. [13:33:54] :) [13:33:58] sounds familiar [13:35:01] Now I need to decide whether to require it to have a target object, like PropertySet... [13:35:29] Hm. No, can't really do that. [13:35:47] Better to have a non-component constructor, and let it receive its parent via suggestion, when used in a component. [13:40:28] It looks like you won't be able to use a Namespace to access the names 'get', 'computeProperty', and 'setParentComponent'. [13:40:54] is acceptable imho [13:41:23] Yeah... 'get' is really the only one that bugs me. The other two I can get rid of easily, by putting them on an adapter class. [13:41:35] (Since they're only used by internal calls that adapt() first) [13:41:45] ok [13:42:37] Ah, what the heck. You're right, no use worrying about it. It only affects __getattr__, not the other uses. [13:42:52] You can use ns['get'] if you really need it for something. [13:43:30] you couldn't write ns.class as well .. [13:43:44] so i wouldn't bother [13:44:15] Yeah, but you can bind to 'ns/class', which is actually the use case the __getattr__ is intended for anyway. [13:44:32] Also, you can't use any names with leading '_' for that, so as not to confuse Python. [13:44:44] E.g. 'ns/__foo__' would be illegal. [13:44:51] ok [13:44:57] You'd again have to use ns['__foo__'] [14:00:35] Looks like it works pretty good so far... I think I'll try seeing if replacing PropertySet would work, too. [14:28:59] * pje checks in the code [14:29:02] Done! [14:29:20] Now to see about integrating it into the SQL connection drivers. [14:47:28] * pje checks it in again [14:49:25] ** Maniac has joined us [14:56:56] oo, peak action [14:59:52] hey maniac :) [15:08:41] pje: the URL.getCanonicalBody gives back the remaining parts of the url as string or Compound/CompositeName, correct ? [15:09:36] err .. not remaing parts but the body without scheme-prefix .. [15:12:08] ** pje has joined us [15:12:08] ** radekk has joined us [15:12:08] ** pyniac has joined us [15:13:50] {global notice} Hi all! it appears as if we've lost our main european hub with services on it. I'm looking at the situation, and will give updates in wallops [15:16:07] ** pyniac has joined us [15:16:07] ** radekk has joined us [15:16:07] ** pje has joined us [15:17:50] ** pyniac has joined us [15:17:50] ** radekk has joined us [15:17:50] ** pje has joined us [15:21:20] ** radekk has left us [16:31:38] * pje is gonna go get some food [16:33:54] * pje is away: I'm busy [16:37:14] ** hazmat has joined us [16:41:45] back [16:48:45] pje: would you have a minute for some zconfig questions? [16:49:08] its not directly peak related, but i can't find anyone on irc at the moment besides yourself who might be able to shed some light on it [16:49:54] Sure, go for it. [16:50:46] ok, i'm trying to do some really basic things, like defining section types.. so say for example this is my schema [16:51:11] [16:51:11] [16:51:11] [16:51:11] [16:51:11] [16:51:14] [16:51:42] the schema loads fine but when i try to load a config file i get loading errors [16:52:02] hey hazmat :)) welcome to #peak [16:52:23] bar 1 [16:52:23] [16:52:23] var 1 [16:52:23] [16:52:26] same conf above [16:52:30] hi jack-e, thanks [16:52:51] what error do you get ? [16:52:52] >>> s = ZConfig.loadSchema('schema.xml') [16:52:52] >>> l = ZConfig.loadConfig(s, 'test.conf') [16:53:02] ZConfig.ConfigurationSyntaxError: no matching section defined for type='trivial', name='None' [16:53:02] (line 2 in file:///Users/hazmat/Research/zope3/geddon/src/test.conf) [16:53:11] stack trace omitted [16:53:45] Hm. [16:53:48] i can't seem to get any zconfig functionality (sections/components) working minus simple key based configs. [16:54:07] Oh... [16:54:11] I see your problem. [16:54:19] * hazmat listens intently [16:54:25] You don't have a
block in the schema. [16:54:32] It's not enough to have a sectiontype... [16:54:55] Sectiontype is like the class, section is the *attribute*. [16:55:03] hmm.. ok, whats interesting is what happens when i do add section... [16:55:11] So, your schema needs a
[16:56:06] yup.. but you can seem to declare instance attributes .. ala [16:56:08]
[16:56:08] [16:56:08]
[16:56:08] [16:56:13] er. can't [16:56:44] that fails with ZConfig.SchemaError: 'key' elements may not be nested in 'section' elements (line 8, column 5), but ok [16:57:01] Right. You put those in the section *type*. [16:57:02] so i say just add the section without a key as an empty element [16:57:26] Think of it as classes and attributes. Each is a classs, and the keys or
s within it are its instance attributes. [16:57:43] The schema as a whole is *also* a sectiontype... so you put keys and sections in it, specifying the types. [16:57:51] You never put anything inside a
or [16:58:00] then it fails with ZConfig.ConfigurationSyntaxError: unknown type name: 'foo' [16:58:00] (line 2 in file:///Users/hazmat/Research/zope3/geddon/src/test.conf) [16:58:31] Er, your conf should say not [16:58:33] so i added the section, altered the section name in conf to foo, and then i get this error [16:58:34] ah [16:58:43] , IOW [16:59:04] wohoo! [16:59:05] Or you can define it as
and just say [16:59:13] thank you [16:59:18] Unless you have more than one section of type trivial in the containing type. [16:59:42] i got the other stuff multisections and name="*" [16:59:47] i just couldn't get started [16:59:54] thank you [17:01:45] No problem. [18:54:57] Gotta head out... [18:55:02] cu [18:55:07] Thanks for your help. [18:55:21] ** pje has left us [21:23:26] ** hazmat has joined us [23:34:57] ** hazmat has joined us