Menu
▾
▴
sooc-devel — Discussion of Sooc development
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(18) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Mike R. <mik...@gm...> - 2007-08-23 02:38:49
|
Forwarded Conversation Subject: Sooc on Win32 ------------------------ From: Dan Reinish <de...@cm...> To: mik...@gm... Date: Wed, Aug 22, 2007 at 1:12 AM Let me preface this e-mail by pointing out that I was bored. Now, that being said, I decided to look into the perils of the Win32 platform, since this is something we discussed once before. Yes, I could have done something practical like writing documentation or (gasp!) actual code. But no....I was far more intrigued by this... Anyway, I installed MingW and jumped through hoops to get automake 1.8 and autoconf 2.59 on the system (automake 1.9 was available; however, "aclocal" would not produce any output at all). This configuration worked just fine once I instructed sooc to use the older version. After this, I needed to get the win32 version of pthreads and a regex implementation that was available directly from the MingW repository. With these necessary libraries on hand, I attempted to compile Sooc. Now, keep it mind that I have skipped over many dreary details about what happened in between all these *successful* steps. In any case, the long and the short of it is that with the necessary versions of autotools and those two libraries installed on top of the basic MingW stuff, Sooc appeared to compile to some extent. Specifically, I ended up with libsooc.a and libsooc.la. There was no shared library/dll produced, however, and I'm not 100% sure how one causes that to happen (or if its absence is even an error). Library confusion aside, what this does show, I think, is that if the config files were changed to make sooc intentionally produce a static library, we would have something that could be directly linked to windows software for use of sooc-style programming. Not that I want to do that. i'm just relaying the news... -------- From: Mike Richman <mik...@gm...> To: Dan Reinish <de...@cm...> Date: Wed, Aug 22, 2007 at 2:09 AM I'm glad you've had this much success with Sooc + win32. In fact, I have been down that road as well. I'm not really sure how static libraries work on win32, but I know that dynamic libraries have very specific and (to me) confusing demands about object and function definitions at link time. I don't know what your tools generated, but I received clear errors to the effect that a .dll could not be built due to undefined symbols. Of course, it's not at all obvious which symbols were undefined. I read lots of information online, but none of the advice helped me ensure that all the symbols were defined. If we could do a static library, that would definitely be a great start. I also want to try building Sooc with Dev-C++... I have no idea what this would involve. If it works, though, then I would recommend adding the Dev-C++ files to svn and maintaining them so Sooc can be built as natively as possible on both platforms. Do you mind if I forward this message to soo...@li... ? -Mike [Quoted text hidden] -------- From: Dan Reinish <de...@cm...> To: Mike Richman <mik...@gm...> Date: Wed, Aug 22, 2007 at 5:55 PM You can forward it to sooc-devel. I should add, and you may want to include this, that there was actually a warning printed to the terminal in the middle of all the linking and archiving. It was not an error however, just a warning. By examining the output of a "normal" OS X compilation, I was able to deduce that this warning message occurred exactly where the process that produces the .dylib takes place. So, it is still possible that "make" attempted to produce the DLL but could not because, as you alluded to, no attempt was made to do all the proper declarations required for DLLs to work (and maybe this had something to do with the undefined symbols). [Quoted text hidden] -------- |
|
From: Dan R. <sta...@gm...> - 2007-08-21 20:23:47
|
Okay, that sounds reasonable enough. On 8/21/07, Mike Richman <mik...@gm...> wrote: > > If we port a gtkmm project, we will have to work with GObject to an > extent. In particular, a C++ project is likely to include derived > widgets. Those are a major pain with GtkWidget. But with Sooc, they > can be expressed using a combination of composition and inheritance, > which I did easily enough in OTweeze. The SGtkWidget wrapper for > GtkWidget was designed in like 5 minutes and it was straightforward > enough to use. In fact, it's because this is exactly the sort of > challenge Sooc needs to handle gracefully that I think a gtkmm project > would be appropriate. Also, the gtkmm website maintains a list of > some client projects, which might be a good starting point in choosing > a project. > > That said, a completely different project might be still more > appropriate. I'll be thinking about C++ and Java apps I know of... or > maybe we can just find something on SF somewhere :) > > -Mike > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
|
From: Mike R. <mik...@gm...> - 2007-08-21 04:38:46
|
If we port a gtkmm project, we will have to work with GObject to an extent. In particular, a C++ project is likely to include derived widgets. Those are a major pain with GtkWidget. But with Sooc, they can be expressed using a combination of composition and inheritance, which I did easily enough in OTweeze. The SGtkWidget wrapper for GtkWidget was designed in like 5 minutes and it was straightforward enough to use. In fact, it's because this is exactly the sort of challenge Sooc needs to handle gracefully that I think a gtkmm project would be appropriate. Also, the gtkmm website maintains a list of some client projects, which might be a good starting point in choosing a project. That said, a completely different project might be still more appropriate. I'll be thinking about C++ and Java apps I know of... or maybe we can just find something on SF somewhere :) -Mike |
|
From: Dan R. <sta...@gm...> - 2007-08-20 22:40:03
|
Doesn't gtk+ use GObject? I thought maybe that porting a GUI app that uses the GObject hierarchy would make the Sooc object system less obvious. Or at least it would add complication to this test. On 8/20/07, Mike Richman <mik...@gm...> wrote: > > I don't know that it has to be a console utility. We should really > just be looking for something reasonably small writtenin C++ or Java. > If a GUI is involved, we can port it to GTK+. I know this would > complicate the comparison of Sooc with the other object systems, but > Sooc needs to be proven to work well with GTK+ to be practical anyway. > There's nothing wrong with learning a little Swing, gtkmm, Qt, > networking, image handling, or any other random thing on the fly, I > don't think. This is especially true if we focus primarily on porting > the object system itself and only worry about the underlying > algorithms in the original code if we need to change it. > > So... what small utilities do we (I?) like and would we (I?) be > interested in porting? I'll be thinking about it; let me know if you > come up with anything. > > -Mike > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
|
From: Mike R. <mik...@gm...> - 2007-08-20 22:27:55
|
I don't know that it has to be a console utility. We should really just be looking for something reasonably small writtenin C++ or Java. If a GUI is involved, we can port it to GTK+. I know this would complicate the comparison of Sooc with the other object systems, but Sooc needs to be proven to work well with GTK+ to be practical anyway. There's nothing wrong with learning a little Swing, gtkmm, Qt, networking, image handling, or any other random thing on the fly, I don't think. This is especially true if we focus primarily on porting the object system itself and only worry about the underlying algorithms in the original code if we need to change it. So... what small utilities do we (I?) like and would we (I?) be interested in porting? I'll be thinking about it; let me know if you come up with anything. -Mike |
|
From: Dan R. <sta...@gm...> - 2007-08-20 21:10:22
|
Mike, Your reasoning here makes a lot of sense. While I still propose following my aforementioned exercise at some point as a sort of post mortem, we definitely do need to see how Sooc stacks up to external needs. I imagine we need to select some kind of console-based utility to port. At the moment, however, nothing is really coming to mind. But I will think about it and get back to you if I have any ideas. --Dan On 8/20/07, Mike Richman <mik...@gm...> wrote: > > I'm talking about a third-party project. The reason is simple enough: > Sooc was designed with our, and especially my, needs in mind. Now we > need to see how it applies to others' design. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
|
From: Mike R. <mik...@gm...> - 2007-08-20 11:29:55
|
I'm talking about a third-party project. The reason is simple enough: Sooc was designed with our, and especially my, needs in mind. Now we need to see how it applies to others' design. |
|
From: Dan R. <sta...@gm...> - 2007-08-20 03:52:00
|
Are you talking about code from a "real," third-party project or something that you or I have worked on? Aside from that, I believe I have told you before that I have always thought that some sort of official sample program should be part of the overall Sooc project. Such a program would be useful in order to demonstrate the structure of a Sooc program as well as the usefulness of the library in general. Consequently, I am all for your idea. I think, ideally, at some point, we should have a program written in several different languages, such as C/Sooc, C++, Java, and Objective-C. One might even consider throwing traditional C or C/Glib in there (you know, just for fun). But the idea would be to provide a reasonable comparison across programming techniques. On 8/19/07, Mike Richman <mik...@gm...> wrote: > > I've invested rather a lot of time into this project. Certainly it > accounts for the vast majority of my coding time over the past year or > more. The base system of Sooc is more powerful than ever, and the > accompanying class library is steadily improving. But now I'm > wondering, as I have on occasion before, whether Sooc is a productive > endeavor. > > I thought of a real test of Sooc's usefulness. We could rest assured > that it is a Good Thing if we (or I) port a C++ or Java project to > Sooc and the result is more manageable code. If the code just grows > uglier or more confusing, it is a pretty safe bet that Sooc is only > valuable as an exercise in OOP. > > I don't propose halting development. In fact, I have a few important > ideas about the collections module that really should be implemented. > Nonetheless, I want to start working in parallel on a port of some > existing code as soon as possible. > > Any thoughts? Ideas as to which code to port would be especially handy. > > -Mike > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
|
From: Mike R. <mik...@gm...> - 2007-08-20 00:50:20
|
I've invested rather a lot of time into this project. Certainly it accounts for the vast majority of my coding time over the past year or more. The base system of Sooc is more powerful than ever, and the accompanying class library is steadily improving. But now I'm wondering, as I have on occasion before, whether Sooc is a productive endeavor. I thought of a real test of Sooc's usefulness. We could rest assured that it is a Good Thing if we (or I) port a C++ or Java project to Sooc and the result is more manageable code. If the code just grows uglier or more confusing, it is a pretty safe bet that Sooc is only valuable as an exercise in OOP. I don't propose halting development. In fact, I have a few important ideas about the collections module that really should be implemented. Nonetheless, I want to start working in parallel on a port of some existing code as soon as possible. Any thoughts? Ideas as to which code to port would be especially handy. -Mike |
|
From: Dan R. <sta...@gm...> - 2007-08-17 00:43:22
|
Sooc r168 (with updated base class, etc.) will not compile on my OS X setup. "Make" fails in the linking stage with the following output: ld: multiple definitions of symbol _class_SMeta .libs/s-classes.o definition of _class_SMeta in section (__DATA,__common) .libs/s-except.o definition of _class_SMeta in section (__DATA,__common) .libs/s-gen-base.o definition of _class_SMeta in section (__DATA,__common) .libs/s-gen-std.o definition of _class_SMeta in section (__DATA,__common) .libs/s-meta.o definition of _class_SMeta in section (__DATA,__common) .libs/s-object.o definition of _class_SMeta in section (__DATA,__common) .libs/s-thread.o definition of _class_SMeta in section (__DATA,__common) .libs/s-utilities.o definition of _class_SMeta in section (__DATA,__common) .libs/s-array.o definition of _class_SMeta in section (__DATA,__common) .libs/s-binary-node.o definition of _class_SMeta in section (__DATA,__common) .libs/s-iterable.o definition of _class_SMeta in section (__DATA,__common) .libs/s-linked-list.o definition of _class_SMeta in section (__DATA,__common) .libs/s-list.o definition of _class_SMeta in section (__DATA,__common) .libs/s-queue.o definition of _class_SMeta in section (__DATA,__common) .libs/s-stack.o definition of _class_SMeta in section (__DATA,__common) .libs/s-array-iter.o definition of _class_SMeta in section (__DATA,__common) .libs/s-array-rev-iter.o definition of _class_SMeta in section (__DATA,__common) .libs/s-const-iter.o definition of _class_SMeta in section (__DATA,__common) .libs/s-const-rev-iter.o definition of _class_SMeta in section (__DATA,__common) .libs/s-iter.o definition of _class_SMeta in section (__DATA,__common) .libs/s-linked-list-iter.o definition of _class_SMeta in section (__DATA,__common) .libs/s-linked-list-rev-iter.o definition of _class_SMeta in section (__DATA,__common) .libs/s-rev-iter.o definition of _class_SMeta in section (__DATA,__common) .libs/s-func1.o definition of _class_SMeta in section (__DATA,__common) .libs/s-comparable.o definition of _class_SMeta in section (__DATA,__common) .libs/s-double.o definition of _class_SMeta in section (__DATA,__common) .libs/s-float.o definition of _class_SMeta in section (__DATA,__common) .libs/s-int.o definition of _class_SMeta in section (__DATA,__common) .libs/s-long.o definition of _class_SMeta in section (__DATA,__common) .libs/s-short.o definition of _class_SMeta in section (__DATA,__common) .libs/s-ulong.o definition of _class_SMeta in section (__DATA,__common) .libs/s-uint.o definition of _class_SMeta in section (__DATA,__common) .libs/s-ushort.o definition of _class_SMeta in section (__DATA,__common) .libs/s-num.o definition of _class_SMeta in section (__DATA,__common) .libs/s-file.o definition of _class_SMeta in section (__DATA,__common) .libs/s-regex.o definition of _class_SMeta in section (__DATA,__common) .libs/s-stream.o definition of _class_SMeta in section (__DATA,__common) .libs/s-string.o definition of _class_SMeta in section (__DATA,__common) /usr/bin/libtool: internal link edit command failed make[1]: *** [libsooc.la] Error 1 make: *** [all] Error 2 |
|
From: Mike R. <mik...@gm...> - 2007-08-16 23:04:05
|
fixed. |
|
From: Dan R. <sta...@gm...> - 2007-08-16 21:10:49
|
s-meta is missing from svn
On 8/16/07, Mike Richman <mik...@gm...> wrote:
>
> Here is the game plan I recently outlined:
>
> 1) Create class messages ("static" messages). This is easy.
>
> 2) Reorganize the object creation process. Get some memory with the
> 'alloc' class message, then init the object with the init method
> (which still automatically calls parent constructors and such). This
> is what we do right now: an alloc *method*, not message, gets some
> memory with calloc(), calls the init method, and returns a properly
> formed object. So the old way could be referred to as
> "ass-backwards"... if you will. I'll fix it.
>
> 3) Then I'll get rid of the "memory" module or whatever by bringing
> the memory management in as SObject methods. There's no real need to
> make retain/release/auto_release messages. You just need the 'alloc'
> class message and a corresponding 'free' message.
>
> 4) Next I'll carefully create a true base class that contains only
> the bare minimum for a top-level Sooc class. I'll get rid of all the
> hackish code that is SObject and rewrite the boilerplate in terms of
> Sooc macros so it will be a genuine abstract class.
>
> 5) When the base system finally makes sense, I'll start rewriting all
> the method prototypes to use typed parameter pointers, while
> continuing to use generic self- and return-value-pointers.
>
> Tonight I finished 1-4. It went rather well. The base class is
> SMeta. SIface is more elegant because it uses SMetaClass as a base
> (just as SObject and SObjectClass build on SMeta and SMetaClass).
> Externally managed objects are now possible with s_ext_bless() before
> use and s_ext_clean() after. [Note: I was referring to these as
> unmanaged earlier, with s_unmanaged_bless() and s_unmanaged_clean(),
> but those names were confusing and unnecessarily long.]
>
> So it's time for an updated Game Plan.
>
> -Mike
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Sooc-devel mailing list
> Soo...@li...
> https://lists.sourceforge.net/lists/listinfo/sooc-devel
>
|
|
From: Mike R. <mik...@gm...> - 2007-08-16 09:16:30
|
Here is the game plan I recently outlined:
1) Create class messages ("static" messages). This is easy.
2) Reorganize the object creation process. Get some memory with the
'alloc' class message, then init the object with the init method
(which still automatically calls parent constructors and such). This
is what we do right now: an alloc *method*, not message, gets some
memory with calloc(), calls the init method, and returns a properly
formed object. So the old way could be referred to as
"ass-backwards"... if you will. I'll fix it.
3) Then I'll get rid of the "memory" module or whatever by bringing
the memory management in as SObject methods. There's no real need to
make retain/release/auto_release messages. You just need the 'alloc'
class message and a corresponding 'free' message.
4) Next I'll carefully create a true base class that contains only
the bare minimum for a top-level Sooc class. I'll get rid of all the
hackish code that is SObject and rewrite the boilerplate in terms of
Sooc macros so it will be a genuine abstract class.
5) When the base system finally makes sense, I'll start rewriting all
the method prototypes to use typed parameter pointers, while
continuing to use generic self- and return-value-pointers.
Tonight I finished 1-4. It went rather well. The base class is
SMeta. SIface is more elegant because it uses SMetaClass as a base
(just as SObject and SObjectClass build on SMeta and SMetaClass).
Externally managed objects are now possible with s_ext_bless() before
use and s_ext_clean() after. [Note: I was referring to these as
unmanaged earlier, with s_unmanaged_bless() and s_unmanaged_clean(),
but those names were confusing and unnecessarily long.]
So it's time for an updated Game Plan.
-Mike
|
|
From: Dan R. <sta...@gm...> - 2007-08-15 05:24:01
|
Greetings, sir! What sooc you so long? --Dan On 8/15/07, Mike Richman <mik...@gm...> wrote: > > This is the first message for soo...@li..., the first > mailing list for Sooc. > > Dan, please reply so we can make sure it works correctly. :) > > -Mike > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sooc-devel mailing list > Soo...@li... > https://lists.sourceforge.net/lists/listinfo/sooc-devel > |
|
From: Mike R. <mik...@gm...> - 2007-08-15 05:21:50
|
This is the first message for soo...@li..., the first mailing list for Sooc. Dan, please reply so we can make sure it works correctly. :) -Mike |
