siop-development Mailing List for Scripting Inter-Operation Protocol
Status: Pre-Alpha
Brought to you by:
slobberchops
You can subscribe to this list here.
2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Rapheal K. <ra...@ma...> - 2006-07-16 02:17:04
|
I put a release file up on Sourceforge just in case anyone wanted to do a simple download without needing to hook in to the CVS server. Hopefully, this might encourage new people to take a look and TRY to figure out what SIOP/SNAPP is doing. It's only a source tar-ball. |
From: Rapheal K. <ra...@ma...> - 2006-07-03 17:31:10
|
>> Now it's a little easier: >> >> >> # Helper method to define Python class >> # In the future, may provide helper library to do this >> def pyclass( name, *parents, &definition ) >> klass = $types.ClassType( name.to_s, >> Siop::val( Siop::Tuple( *parents ) ), >> Siop::val( {} ) >> ) >> klass.instance_eval &definition unless definition.nil? >> klass >> end >> > > I would hope that code like this would be part of the siop framework, at > least at some point. You're not going to expect a siop user like me to > write or maintain code like that, are you? > > Meaning, siop will include code for creating classes? I think that class creation should be one of the levels. Then it would be a lot simpler to code the above thingy. There would, for one, be no need to do the val thing nor the tuple thing, because the bridge on the receiving side could take care of all of that for you. > I had a similar reaction to the wxRython snippets...they seemed to be a > mix of generic and specific code. I don't want to see the sausage-making > generic code. It's all about encapsulating the icky parts into the > framework so clients like us can just use remote classes and objects as > if they were local. > > Something like this would be cool: > > class MyApp < siop.remote_class(:wx, :App) > def on_init > # blah blah blah > end > end > Right, that's what I am thinking. |
From: Kevin S. <wx...@qu...> - 2006-07-03 14:31:11
|
On Thu, 2006-06-29 at 00:43 -0700, Rapheal Kaplan wrote: > I've added a "ref" and "val"... err... modifier? Not sure what to call > them. Seems ok. > Remember, scalar values are passed by value by default while collections are > passed by reference by default. Still sounds irritating to me, as one who is constantly fuming about the scalar/object distinction in Java. Maybe this wouldn't be so bad, since as I mentioned Ruby passes ints by reference but they appear to be passed by value since they are immutable. > Now it's a little easier: > > > # Helper method to define Python class > # In the future, may provide helper library to do this > def pyclass( name, *parents, &definition ) > klass = $types.ClassType( name.to_s, > Siop::val( Siop::Tuple( *parents ) ), > Siop::val( {} ) > ) > klass.instance_eval &definition unless definition.nil? > klass > end I would hope that code like this would be part of the siop framework, at least at some point. You're not going to expect a siop user like me to write or maintain code like that, are you? I had a similar reaction to the wxRython snippets...they seemed to be a mix of generic and specific code. I don't want to see the sausage-making generic code. It's all about encapsulating the icky parts into the framework so clients like us can just use remote classes and objects as if they were local. Something like this would be cool: class MyApp < siop.remote_class(:wx, :App) def on_init # blah blah blah end end Kevin |
From: Rapheal K. <ra...@ma...> - 2006-06-29 07:43:36
|
I've added a "ref" and "val"... err... modifier? Not sure what to call them. They are intended to be simple markers that a host language can use as a hint to the bridge so that the bridge knows to over-ride the default parameter behavior for an object being passed to a peer either via parameters or return value. Remember, scalar values are passed by value by default while collections are passed by reference by default. These little keyword thingies can over-ride this default behavior. So, let's say you were calling a method that uses a list. It might be the case that the programmer can figure out that it would be an optimization to send the list to the other side, especially if the code over there does a lot of random access: remote_object.helpful_method( val( [ "a", "b", "c", "d" ] ) ) The example above would send a reference to the list if it were not for the modifier wrapper object. This is very useful in the example wxWidgets code where we needed to construct native Python tuples and dictionaries in order to be able to create new classes: # Helper method to define Python types # Class creation requires actual Python tuples, not pretenders # TODO: This can be disposed of when it is possible to pass # tuples by-value def tuple( *stuff ) list = $types.ListType.call for thing in stuff list.append( thing ) end $types.TupleType( list ) end # Helper method to define Python class # In the future, may provide helper library to do this def pyclass( name, *parents, &definition ) klass = $types.ClassType( name.to_s, tuple( *parents ), $types.DictType.call ) klass.instance_eval &definition unless definition.nil? klass end Now it's a little easier: # Helper method to define Python class # In the future, may provide helper library to do this def pyclass( name, *parents, &definition ) klass = $types.ClassType( name.to_s, Siop::val( Siop::Tuple( *parents ) ), Siop::val( {} ) ) klass.instance_eval &definition unless definition.nil? klass end Anyone who thinks they follow this and cares to voice their opinion as to wether this seems ok or is cumbersome, or thinks there might be a more preferable way, please tell me. - Rafe |
From: Kevin S. <wx...@qu...> - 2006-06-26 01:05:33
|
We're using json on the CMP project, as a data storage format. I really like it. The "standard" java bindings are under a crazy license that's not compatible with any other license on the planet (and probably isn't enforceable either). Fortunately, we found an earlier version that was under a very liberal license, and it has worked fine for us. Feel free to ask off-list for more details. Kevin On Sun, 2006-06-25 at 16:21 -0700, Rapheal Kaplan wrote: > I reckon JSON could actually provide a decent way to implement a useful text > protocol for the SIOP transport layer. Does anyone know it? > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Siop-development mailing list > Sio...@li... > https://lists.sourceforge.net/lists/listinfo/siop-development |
From: Rapheal K. <ra...@ma...> - 2006-06-25 23:21:26
|
I reckon JSON could actually provide a decent way to implement a useful text protocol for the SIOP transport layer. Does anyone know it? |
From: Rapheal K. <ra...@ma...> - 2006-06-25 08:58:52
|
There you have it. Now none of you have an excuse for not looking at Siop. Since I am doing Java bindings now, I have created and checked in an Eclipse project. That means that those of you who need to use Eclipse to get dressed every morning can look at stuff. Like the Python bindings, I am finding there is a lack of unit tests that I am running on the Java code directly. This is a bug, not a feature. In the meantime, I am able to still use the Python tests to check the compatibility. Indeed, Java's bindings already pass a number of the pipe tests. I also went looking around at a few other projects on Sourceforge. I think that this is the farthest something like this ever got, and some people had similar ideas. I feel good about it. All the pieces seem to be making sense, at least to me, but then it always seems like that when I work alone. - Rafe |
From: Rapheal K. <ra...@ma...> - 2006-06-23 20:32:28
|
I am getting a head start on the SIOP Java bindings. Very exciting. Hear that Nathan? I am beating you to the punch, just as if it was important. |
From: Rapheal K. <ra...@ma...> - 2006-06-20 05:23:59
|
I found a use for Tuples in Ruby, but you will hate it, and frankly I think it's a little weird. However, these kinds of differences in how languages works needs to be allowed. The ruby [] operator can take between 1 and 2 parameters. It's the only language that comes to mind that allows for this kind of syntax. Everyone else either supports slicing or doesn't support multiple indices at all. The semantics of Siop seeing a tuple sent to a subscript operator could be to make a two parameter call. So in Python, you might write: remote_ruby_list[ (4,10) ] # Fetch list starting at 4 and going to 10 Actually this syntax would work in Python, it so happens, as well (creates a tuple): remote_ruby_list[4,10] # Fetch list starting at 4 and going to 10 Similarly, Java: remoteRubyList.get( new Integer{4,10} ); To access a Hash which contains keys that are lists in Python, you would use lists: remote_ruby_hash[ [1,2,3] ] # Fetch item with key [1,2,3]. Of course, Python would interpret accept list and tuples as parameters because it accepts either (whether or not your class can handle lists is another question). This would be a use for having an actual tuple for Ruby, although all those other languages still don't have a use for it. > > I think it makes sense for SIOP to have the notion of a Tuple type. > > Forgive my python ignorance, but what is a tuple and why would I want > one? > > >From a brief glance at a couple python pages, it seems that a tuple is a > > readonly array. Is that really a useful thing? I can't actually think of > any case in my life that I have wanted one. > > I guess the bigger question is whether you plan to support the cool > extra feature of each language, or aim for more of a common subset. > > Kevin |
From: Rapheal K. <ra...@ma...> - 2006-06-20 00:53:32
|
I guess it's worth thinking about how many languages have an analogue for a Python Tuple. I think I've only come up with Python, Java and C#. What are the other set of languages out there and what are their Tuple analogs: Javascript - None Lisp - None Perl - None Groovy - Java Arrays C/C++ - Arrays, pointers D - Static arrays Php - None Bash - None OCAML - Tuples Smalltalk - None What else? I think Php is an interesting case because it will be tricky to distinguish between a list and a dictionary as it implements both the same way. Bash doesn't really have dynamic arrays, technically, it's all Tuples. Even though Tuples are now implemented, I am not necessary sold on keeping them in there. However, I would like to think about straight forward solutions so that it is fairly easy to get static arrays and tuples to appear in places where they support it. I am ok with the idea that some constructs are only supported by subset of languages. As long as each binding has a way of dealing with those constructs. Again, Php is going to face this problem no matter what. > > I think it makes sense for SIOP to have the notion of a Tuple type. > > Forgive my python ignorance, but what is a tuple and why would I want > one? > > >From a brief glance at a couple python pages, it seems that a tuple is a > > readonly array. Is that really a useful thing? I can't actually think of > any case in my life that I have wanted one. > > I guess the bigger question is whether you plan to support the cool > extra feature of each language, or aim for more of a common subset. |
From: Rapheal K. <ra...@ma...> - 2006-06-19 20:41:22
|
> On Sat, 2006-06-17 at 18:33 -0700, Rapheal Kaplan wrote: > > I think it makes sense for SIOP to have the notion of a Tuple type. > > Forgive my python ignorance, but what is a tuple and why would I want > one? > > >From a brief glance at a couple python pages, it seems that a tuple is a > > readonly array. Is that really a useful thing? I can't actually think of > any case in my life that I have wanted one. > > I guess the bigger question is whether you plan to support the cool > extra feature of each language, or aim for more of a common subset. > This is a really good question and previously I had dwelled on whether or not to support it. Fact is that many languages will have some sort of differentiation. Pythons reasoning for having tuples vs lists is relatively sound. It has to do with the idea that hashable objects should be immutable. So, for example, this means in Python you can't use a list as a key to a dictionary. You can however, use a Tuple as a key to a dictionary. Ruby allows lists to be used as keys. In Java, a tuple would more likely fit in with an Array (I intend for java.util.List to map to the list type). This would also really means that immutability is not really a requirement for SIOP tuples so much as that they are statically sized lists. The idea would be to supply Ruby with the ability to explicitly create and handle tuples so that they can pass them to other programs. I think that not implementing Tuples in Ruby might be ok (as in, if it receives a Tuple instance it simply returns a list and doesn't care about it's original type). However, there really does need to be a way for Ruby to indicate static sized arrays to a number of other programming languages. Again, maybe it could be handled in the casting Level rather than by implementing a Tuple object. Either way, the syntax in Ruby is not cumbersome. You can work with lists all the way until you reach a method that requires it: my_list = [ 1,2,3,4 ] ... do stuff with list, make it bigger, etc... python_object.needs_a_tuple( Siop.Tuple(my_list) ) |
From: Rapheal K. <ra...@ma...> - 2006-06-19 20:32:32
|
> > Question for folks... should the default mode of returning/sending > > values from method calls be by reference or by value for abstract types? > > Speaking from a ruby standpoint, I think by-reference would be easiest > and least surprising. In ruby, simple objects like integers are > (conceptually) passed by reference...but they are immutable objects, so > the effect is as if you had passed them by value. > > Speaking from an agile standpoint, I would be inclined to support only > by-reference until a case came up that made it unworkable. At that > point, a by_value wrapper would (hopefully) solve it. > That was my thinking on it. Integers and floats, however, will be passed by value. There is sort of already a use case, and as this is geared toward being compatible, it makes sense to support code where it requires an explicit certain type rather than just an interface. This will certainly be the case for things like Java and it is already the case for the Python class structure, where the inheritence parameters require an actual tuple object. That's why in my example I use the Python tuple class to construct a tuple rather than just passing in a Ruby list which I would have definitely preferred to have done. But you are right, I am not going to rush it. I think the next "Level" of SIOP should deal with these data typing/casting issues. |
From: Kevin S. <wx...@qu...> - 2006-06-19 03:23:21
|
On Sat, 2006-06-17 at 18:33 -0700, Rapheal Kaplan wrote: > I think it makes sense for SIOP to have the notion of a Tuple type. Forgive my python ignorance, but what is a tuple and why would I want one? >From a brief glance at a couple python pages, it seems that a tuple is a readonly array. Is that really a useful thing? I can't actually think of any case in my life that I have wanted one. I guess the bigger question is whether you plan to support the cool extra feature of each language, or aim for more of a common subset. Kevin |
From: Kevin S. <wx...@qu...> - 2006-06-19 03:19:40
|
On Sat, 2006-06-17 at 17:05 -0700, Rapheal Kaplan wrote: > Question for folks... should the default mode of returning/sending values > from method calls be by reference or by value for abstract types? Speaking from a ruby standpoint, I think by-reference would be easiest and least surprising. In ruby, simple objects like integers are (conceptually) passed by reference...but they are immutable objects, so the effect is as if you had passed them by value. Speaking from an agile standpoint, I would be inclined to support only by-reference until a case came up that made it unworkable. At that point, a by_value wrapper would (hopefully) solve it. Kevin |
From: Rapheal K. <ra...@ma...> - 2006-06-18 01:33:32
|
I think it makes sense for SIOP to have the notion of a Tuple type. It's obviously very straight forward for Python and maps relatively ok to Java array objects (vs. List objects). This question is probably only answerable by Kevin, but does anyone have any idea what the best way to go about supporting Ruby Tuples are? Right now, I've implemented a Tuple class, which is akin to an Array class, only it's immutable. Sort of needed to do it like that as creating an Array subclass bought me very little. I needed to either make the array immediately frozen, or better yet, block the mutation methods. However, that was not enough because all the different ways that lists operate often return NEW arrays. However, for Tuples, it should really return new Tuples. Just wondering. The Tuples in the SIOP Ruby library work. However, if there is a better way, I would rather do that. - Rafe |
From: Rapheal K. <ra...@ma...> - 2006-06-18 00:05:12
|
Question for folks... should the default mode of returning/sending values from method calls be by reference or by value for abstract types? By reference would make for better network performance and would be closer to the way languages actually function, whereas by value would probably be better for compatibility. There is also a question of consistency. Scalar values such as floats, integers and booleans always get sent by value by default. So, if a function returns a boolean, SIOP will return to the client a boolean value for that platform rather than a reference to a boolean object. However, as currently implemented non-scalar values, like lists and tuples are only returned by reference. You need to make a call to "fetch-value" in order to have the server send a copy of those objects back to the client. When it comes to parameters, it should be possible to use simple object wrappers to indicate to the bridge to send objects by reference or value explicitly. For example: remote_object.calculate_some_stuff( by_value( list_of_stuff ) ) The function above might return another list of values. Right now, this means that the client would receive a proxy that is a referenc to the list on the server. If we changed the policy to be by default by value it a) makes the network traffic go up by default and b) makes it more difficult to keep the results of an operation on the server. Also how would we indicate how to return references by value or by reference? Maybe we could have by-reference proxies and by-value proxies. So, to explicity get the above reference by-value, you could do: value_proxy( remote_object ).calculate_some_stuff( list_of_stuff ) All method calls to the value proxy could call a by value version of fetch-attribute and send-message instead of he default. Anybody care to venture thoughts? Does any of this make sense? - Rafe |
From: Rapheal K. <ra...@ma...> - 2006-06-14 07:56:28
|
Ok folks, as an example, I would like to introduce the first Python classes written in Ruby. They look funny now, but once we get up to level 2, implement static arrays and maps, this will look a lot cleaner. I'm thinking that it might even make sense for SIOP to have a level that deals with class definition. I will put this in an example directory. Kevin, the code below actually works... when you resize the window the new size is printed to the console. It's a fully Ruby based wx callback. The trick turned out to be to use this weird "instancemethod" function. Anyway, see if you can figure out what it means... ------------------------------- #!/usr/bin/env ruby require 'siop/pipe' Siop::Pipe.connect '../../scripts/siop-standard-server.py' do |bridge| bridge.fetch_namespace nil, 'wx' bridge.fetch_namespace nil, 'types' bridge.fetch_namespace nil, 'new' rc = bridge.remote_context wx = rc.wx instancemethod = rc.new.instancemethod $types = rc.types def tuple( *stuff ) list = $types.ListType.call for thing in stuff list.append( thing ) end $types.TupleType( list ) end def pyclass( name, parents, &definition ) instance_eval do klass = $types.ClassType( name.to_s, tuple( *parents ), $types.DictType.call ) klass.instance_eval &definition unless definition.nil? klass end end MyApp = pyclass :MyApp, [wx.App] do self.OnInit = proc do | pyself | pyself.frame = MyFrame.call(nil, -1, "This is a test") MyFrame.Show( pyself.frame, true ) pyself.SetTopWindow( pyself.frame ) true end self.OnInit = instancemethod.call( self.OnInit, nil, self ) end MyFrame = pyclass :MyFrame, [wx.Frame] do self.__init__ = proc do | pyself, parent, wid, title| wx.Frame.__init__( pyself, parent, wid, title ) pyself.Bind( wx.EVT_SIZE, pyself.OnSize ) end self.__init__ = instancemethod.call( self.__init__, nil, self ) self.OnSize = proc do |pyself, event| p "Coordinates (#{event.GetSize.call.x}, #{event.GetSize.call.y})" end self.OnSize = instancemethod.call( self.__init__, nil, self ) end app = MyApp.call app.MainLoop.call end |
From: Rapheal K. <ra...@ma...> - 2006-06-12 22:23:01
|
If you think wxWindows is not threaded then I should look in to it. Maybe there is something I am missing. > > Of course... a windowing system IMMEDIATELY has threading issues. The > > call backs are coming in on a different thread, the results are returning > > from the Python server out of order. So, now there are threading issues. > > Hm. Odd. I don't recall seeing multiple threads in wxruby. Maybe > wxpython is causing wx to be threaded "unnecessarily". Just a thought. > > The example is pretty cool, though. Maybe you could find a non-GUI > library that's available in one language and not the the other. I don't > have any ideas, though. > > Kevin |
From: Kevin S. <wx...@qu...> - 2006-06-12 21:55:55
|
On Sun, 2006-06-11 at 23:20 -0700, Rapheal Kaplan wrote: > Of course... a windowing system IMMEDIATELY has threading issues. The call > backs are coming in on a different thread, the results are returning from the > Python server out of order. So, now there are threading issues. Hm. Odd. I don't recall seeing multiple threads in wxruby. Maybe wxpython is causing wx to be threaded "unnecessarily". Just a thought. The example is pretty cool, though. Maybe you could find a non-GUI library that's available in one language and not the the other. I don't have any ideas, though. Kevin |
From: Rapheal K. <ra...@ma...> - 2006-06-12 06:20:44
|
> I would like to see something like that happen. So far, for some Python > like reason, I am not able to hook up callbacks to wxWindows, although > callbacks in general work over SIOP. Maybe the wxPython has a wierd way of > handling setattr. > > This Ruby code works so far - When I figure a few more things out I will > document it on the Wiki... > Of course... a windowing system IMMEDIATELY has threading issues. The call backs are coming in on a different thread, the results are returning from the Python server out of order. So, now there are threading issues. I though about having each message pass through with a sort of call stack identifier. As long as the transport itself is multi-threaded, it should be possible to have multiple threads with multiple call stacks using the bridge. |
From: Rapheal K. <ra...@ma...> - 2006-06-12 05:54:23
|
> > Thanks a lot Kevin. These are exactly the kind of things I need to > > focus on. I would like to make the example of Ruby using wx Windows, > > but I don't want to diss your efforts on the wxRuby stuff. I think I've > > heard it from you, in addition to an out of date Ruby site, but is it > > correct that wx support on Ruby is weak? > > Well, you could refer to "a GUI toolkit" rather than naming wx > specifically. But I actually wouldn't mind if you did use it as an > example. wxruby is "sort of working", but I haven't had the time to > "finish" it, and no other developers have stepped up to take the lead. > > Hey, if there's an easier way to make wx available to ruby apps, I might > jump ship. I'm skeptical about how easy it would be to wrap such a large > library, to bridge a few python/ruby differences, and then to make it > bearable to deploy ruby wx apps on all three major OS's. > > I'm intrigued. I would like to see something like that happen. So far, for some Python like reason, I am not able to hook up callbacks to wxWindows, although callbacks in general work over SIOP. Maybe the wxPython has a wierd way of handling setattr. This Ruby code works so far - When I figure a few more things out I will document it on the Wiki... ------------------------------------------- #!/usr/bin/env ruby require 'siop/pipe' Siop::Pipe.connect '../../scripts/siop-standard-server.py' do |bridge| bridge.fetch_namespace nil, 'wx' wx = bridge.remote_context.wx app = wx.PySimpleApp(0) frame = wx.Frame( nil, -1, "This is a test" ) frame.Show( true ) app.SetTopWindow( frame ) app.MainLoop.call end |
From: Kevin S. <wx...@qu...> - 2006-06-11 06:00:52
|
On Sat, 2006-06-10 at 14:02 -0700, Rapheal Kaplan wrote: > I have posted a FAQ: > > http://siop.net/wiki/index.php?pagename=SiopFaq > > Naturally, there is really only one question that people ask AT ALL, and the > page reflects it. Naturally, this revision could use better wording. How > does one explain what the hell this thing is? For example, how do I explain > it to all of you??!?!!? I think the explanation you have there is actually pretty good...but it has a few gaps. Mostly, how could this thing actually be used? It's funny, because I actually really really wanted something exactly like SIOP a few years ago...but now I can't remember why. I had found a similar project at that time, but it was too immature, and the folks behind it seemed to be a couple junior high tinkerers who had neither the knowledge nor the follow-through to make it work. So what are some examples of how someone might actually benefit from this thing? Could I wrap wxpython and access it from a ruby app, instead of creating wxruby? Could I write a ruby library for something like statistics, and easily make it available to Python and Perl users? Or would this be appropriate to create a web app where the web service part runs as a separate process from the business logic part, even though both are in Ruby? An example is worth a million words. Speaking of examples, a 5-line "server" and 5-line "client" would go a long way toward showing what could be done. Something simple like a getter on an object (employee.name). A more detailed example might demonstrate the "key benefit" of SIOP over CORBA and XMLRPC: automatic wrapping with no IDL declarations. Probably as a separate Q/A: is the protocol binary or human-readable? Although the answer doesn't really matter, it does speak to the priorities of the project (speed vs. ease of debugging). Kevin |
From: Rapheal K. <ra...@ma...> - 2006-06-10 21:02:52
|
I have posted a FAQ: http://siop.net/wiki/index.php?pagename=SiopFaq Naturally, there is really only one question that people ask AT ALL, and the page reflects it. Naturally, this revision could use better wording. How does one explain what the hell this thing is? For example, how do I explain it to all of you??!?!!? |
From: Rapheal K. <ra...@ma...> - 2006-06-06 03:08:31
|
Folks who remember that they signed up to the siop-development mailing list, I have been going through something of an active development phase for SIOP lately. I've been really happy with it. If you all look at the wiki, you will see that there is something of a structure evolving from it. I you check out the siop project from CVS, you can actually use the Ruby bindings to do... well it's not that useful by itself. In it's current state, you can create simple enterprise applications if you keep to a minimum your remote requests. I wouldn't recommend it, of course, especially as there seem to be performance issues with SIOP running over sockets (the pipe based servers run nice and fast though). You need to be prepared for that server to essentially run out of memory, of course, unless someone wants to implement the garbage collection mechanism. This would consist of: 1 - Implementing the "finalize" code for the proxy object. 2 - Implementing the "release-reference" command. I know that nobody knows what I am talking about, but believe me, it makes sense. Otherwise, anyone up for a code review? I know at least one of you is a right bastard about code criticism, and that kind of feedback is probably a good idea for now. - Rafe |
From: Rapheal K. <ra...@ma...> - 2006-06-06 01:39:30
|
Thanks to those who are on this list. SIOP development has ended up going really well since I switched to Ruby. It's a much better language for me as it has real theoretical objects in a way that I think Python sort of lacks. This really helped get things jump started. For the most part, the over-all SIOP protocol structure is looking good... adding new commands and types as I have taken to calling things, is relatively easy, and it functions almost at Level 0 functionality. Level 0 functionality is what I am defining as the absolute minimum parts of the SIOP protocol required to excersize all of things that are capable to do with SIOP. The levels above 0 are meant to further abstract the differences between different programming languages (for example, index based access to values, operator calling, etc.). If anyone is interested, feel free to do a code review of the Ruby code. I am going to start to re-write the Python stuff, so don't even bother. I know at least one of you can be a right bastard about doing reviews, and that's what is necessary. - Rafe |