nutshell-devel — Discussions related to planning and development of Nutshell

Re: [Nutshell-devel] Classes.dia (SID)

[Alexandre M. <ale...@gm...>]

well, with the attachments it feels better...

2006/10/11, Alexandre Moreira <ale...@gm...>:
> Still in development classes diagram for Nutshell's basic code. These
> are gonna be reused throughout all the m=F3dules.
>
> Cheers,
> Alexandre Moreira.
>

[Nutshell-devel] Classes.dia (SID)

[Alexandre M. <ale...@gm...>]

Still in development classes diagram for Nutshell's basic code. These
are gonna be reused throughout all the m=F3dules.

Cheers,
Alexandre Moreira.

Re: [Nutshell-devel] About DAOs

[Alexandre M. <ale...@gm...>]

2006/10/3, Rodrigo Coacci <rc...@gm...>:
> Well, as you asked me to find an API, here it goes:
> http://thaiopensource.org/development/libpqxx/ - its a C++
> wrapper to libpq, the official postgre C API. It's designed to use
> transactions, throw C++ exceptions and results (or ResultSets) are returned
> as smart pointers to objects.

I was rather thinking in using the good official postgre C API wrapped
inside our DAOS... it would spare us the dependency in another lib...
but hey, if this is good enough, we can give it a try.

The only thing I don't like in it is that it would probably make our
code too much "PGsql" based, since we already have the C++ wrapper
classes we will use them, but with the low level API we would wrap it
into some "smart" interface, that we could then reuse if we ever
decided to change to mySQL or Oracle or anything like it...

But, no problems, give it a try, give me some code on how it would be
used to write basic SELECT/INSERT/UPDATE applications and we'll
discuss it.

> OTOH, would we be needing ORM (object-realtional mapping)? Or it's overkill?
> I don't know much of what you are thinking for domain objects, so I can't
> answer that.
>

ORM is not needed at all, I mean, it would be "nice" but is not
*needed*, since most of our code won't even bother with the DBMS code.


> Cheers,
>       Rodrigo
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Nutshell-devel mailing list
> Nut...@li...
> https://lists.sourceforge.net/lists/listinfo/nutshell-devel
>
>
>
Cheers,
Alexandre Moreira.

[Nutshell-devel] About DAOs

[Rodrigo C. <rc...@gm...>]

Well, as you asked me to find an API, here it goes:
http://thaiopensource.org/development/libpqxx/ - its a C++ wrapper to libpq,
the official postgre C API. It's designed to use transactions, throw C++
exceptions and results (or ResultSets) are returned as smart pointers to
objects.
OTOH, would we be needing ORM (object-realtional mapping)? Or it's overkill?
I don't know much of what you are thinking for domain objects, so I can't
answer that.

-- 
Cheers,
      Rodrigo

[Nutshell-devel] Network Class Information : NetworkControl and NetworkAdapter

[Alexandre M. <ale...@gm...>]

Now, in the last important part of the description, the "glue code"
comes to aid in the task of making a sense out of it all.
Unfortunately, it is this glue code that I like less, as it is a
concentration of mixed responsabilities in just one object. But then,
this is the fastest way I found to make it work and still look "nice"
in the OO-way-of-life (I don't want any zealots throwing rocks on me
while I walk on the streets)

Those interfaces and classes in the last 2 sections defined how we
handled receiving events and sending data. That is, the "interface"
between our network code and the network.

What I will try to do now is to present the "interface" from the point
of view of our server internals and the network code. the place where
those many streams of bytes become objects used inside the program.

A few interfaces come handy in here:

// this interface is not exactly finished yet, but most of what is not
finished won't be needed in our code... was just planned to make the
classes "complete" outside the definition of Nutshell.
NetworkControl // this is an interface.
public:
 virtual void connect(InetAddress &address, uint16 port) = 0;
 virtual void listen( uint16 port ) = 0;
 virtual void close( int32 ioChannel ) = 0;
 // ... and several other functions that, usually, only wrap calls to
some underlying Socket object. These are just defined because we WILL
need the "close()" one, so the message processing system can create
the action of closing a connection and all its related data.

//The InetAddress class is just a basic class that wraps the
information about a "struct sockaddr_in" and provides some helpers for
gethostbyname() and stuff like this. I will define it when we get to
define the "Socket" class.

Along with this class, we have another interface, that should probably go here.

MessageStream // this is an interface.
public:
  virtual bool hasMessages() = 0;
  virtual Message * fetchMessage() = 0;
  virtual void clearTarget( int32 clientId ) = 0;

Well, those are simple, at least the first two. The last one is a
helper method just to speed things a bit: It is there so that,
whenever we find out that a client is dead (the processing of the hang
up message, for instance) we can tell the queue to discard every
message from that client that is still in the queue... saving us the
trouble of getting the message, making a process out of it and
everything that will come to us later.

Now, for the ugly part of the play, we have the NetworkAdapter... it
is ugly even in the name. I couldn't find a good name for it, so I'm
up for ideas. What exactly does it do ? The following:

First it implements pretty much every interface we saw so far in the
network classes:
it is a MessageStream, an IoSelectorListener, a NetworkControl and a
DataSendSource.

... ... Didn't I Tell you it was ugly ? Yeah, I know it is horrible
but check this... doing it this way, we can have all "socket
information" (the receive buffers, the send queues, and the send
buffers ) insulated inside this one big object. which means that,
whenever we have a read error, and decide we have to disconnect a
client, we waste no time passing this information to every bit of code
that uses information about that client: we just generate some kind of
ClientReadError message to be processed (this will clean this clients
in-game information from our pool) and do the cleaning on the network
stuff : we can tell our IoSelector to unregister it from every event,
delete its sendqueues, clear all the messages we have from it in the
MessageQueue and close the socket.

Ok.. I know it won't justify, that it is still ugly and should not be
made this way... but.... if you give me better Ideas I would LOVE to
hear them... I tried for 3 weeks to make this work... and I am just
unable to do it... not good enough in OO I guess.

All I need is a fast, efficient, pretty, OOized version of this code
that works in the context of Nutshell... :)

all I got was a fast and efficient, ugly and OOWrapped version :)

I'll leave you digesting this... see ya,
Alexandre Moreira.

[Nutshell-devel] Network Class Information : DataSender and DataSendSource

[Alexandre M. <ale...@gm...>]

Continuing the latest series of class description for the project
(yes, I know this all came rather quickly, but they don't allow me to
really work at my work so... I play).

These are much simpler class (yes, it can get simpler than those last
two). You may have noticed that the last bit of information only
really handled (efficiently) receiving data (using onWriteReady to
actually write something wouldn't work since we would need to ... hmm
... actually HAVE something to send before that). So, these companion
classes also work inside our network package to make the communication
flow.

As the IoSelector, the DataSender runs in a separate thread (yes, it
is yet another thread). This may seem odd but hey, now we have
full-duplex writing/reading from the same client code without too much
hassle, and I can only hope that this won't hurt performance.

The DataSender is just a thread that (unsurprisingly) reads from a
DataSendSource and writes it to the ioChannel specified. And a
DataSendSource is just... well... just an interface actually, but in
our framework it will hold a few queues and do the job of handling who
should be sent when.

There they go:

DataSender
public:
 DataSender( DataSendSource & source )
 void operator()(void) // to make it run as a thread.
 void stop(void) // used to stop the main loop in the thread.
private
 DataSendSource& source;
 bool shouldStop;

Along with it goes this class (an interface actually, but C++ is not
silly enough to make these differences)

DataSendSource //this is an interface
public:
 virtual ByteBuffer * fetchData( int32& ioChannel ) = 0;
 void onSendError( int32 ioChannel, in32 error ) = 0;

// The ioChannel in fetchData is actually an "out parameter"...
unfortunately we cannot return multiple values and well.. I didn't
felt like creating an structure just for that.


I think that is enough for now. Anything you wanna know, I'm open for debates.

Cheers,
Alexandre Moreira.

PS: It probably means nothing until now,since the "glue" part is not there yet.

[Nutshell-devel] Network Class Information : IoSelector and IoSelectorListener

[Alexandre M. <ale...@gm...>]

Ok, now we get into the controversial bits of the server structure:
our network classes.

First of all I must say that I didn't achieve a very good result with
any model I tried, so I just decided to use this one, although a bit
troubled: It is not exactly "high level" and it is possible that we
will have to change a few things later when the project is bigger.

The good part, though is that we can pretty much insulate this code
from the rest of the application, since it runs in its own thread and
talks to the rest of the server(s) through queues of messages.

The "Socket" information is not higher level than the raw socket
calls, and I will not talk about it right now: it will only be a
wrapper to the file descriptor, associating socket functions with it
as methods, dealing with a little higher level structures (ByteArrays
instead of char* as an example) and doing error handling through
exceptions.

That being said, most of the interfaces and basic classes of the
system, will deal mostly with the 32 bit integer used as file
descriptor for a socket.

At last, I do not have the names and descriptions of all the
exceptions I planned on using here at hand right now, so I will just
say "throws an exception" where it is due...

There we go:
enum IoSelectionType { IO_SELECTOR_READ, IO_SELECTOR_WRITE,
IO_SELECTOR_EXCEPTION };

IoSelector
public:
 IoSelector( IoSelectorListener& listener );
 void register( int32 ioChannel, IoSelectionType ); //throws an exception
 void unregister( in32 ioChannel, IoSelectionType ); //throws an exception
 void operator()(void) // used when it is run as a thread.
 void stop() // used when it is run as a thread.
private:
 IoSelectorListener& listener;
 fd_set fdReadSet;
 fd_set fdWriteSet;
 fd_set fdExceptionSet;
 // it should have a Mutex here, but I can't remember how the mutexes are
 // expressed in boost::thread. the public methods should acquire the lock
 // while changing the sets.

IoSelectorListener // this is an interface
public:
 virtual void onReadReady( IoSelector& selector, int32 ioChannel ) = 0;
 virtual void onWriteReady( IoSelector& selector, int32 ioChannel ) = 0;
 virtual void onExceptionReady( IoSelector& selector, int32 ioChannel ) = 0;

... As you can see, this is nothing really different from the select()
system call, except that the types are wrapped in pretty
CamelCaseNamed things and it works sorta like an event-driven system.

Some exception generation will go in those classes and it is already
prepared to run looping this select() forever in a separate thread.
Nice... but no high-level at all. What can I say... I always liked the
way select() works.

Perhaps we will have to change select() for poll (or epoll where it is
supported) and then the name Selector will not be exactly intuitive,
but... I tried a lot of names and none of them felt right... whatever.

Until the next bit, folks... see ya,
Alexandre Moreira.

[Nutshell-devel] About Dia2code

[Rodrigo C. <rc...@gm...>]

Alexandre, I simply can't make dia2code work on Arch, after compilation
problems, it simply seg faults.... So if you wish to use generated classes
from dia, you'll have to generate them, as I won't be able to do it....

-- 
Cheers,
      Rodrigo

Re: [Nutshell-devel] Basic class information : Byte Buffer.

[Alexandre M. <ale...@gm...>]

2006/8/26, Rodrigo Coacci <rc...@gm...>:
> Also whats the difference btwn getSize and getCapacity?
>
the Buffer may be partly filled. That way we need a way to learn its
total size (getSize) and another way to find out how much space is
there left in the buffer (getCapacity)... perhaps we can find some new
names for these functions... don't know

Re: [Nutshell-devel] Basic class information : Byte Arrays

[Alexandre M. <ale...@gm...>]

[...]
> >  ByteArray(char * wrappedData, int capacity);
>
>
> Wait a moment, this constructor is really to be private?
> OTOH I don't see a default constructor (as this one is private), did you
> miss this or was intentional?
>
oops! It was a protected constructor, sorry.

Re: [Nutshell-devel] Basic class information : Byte Buffer.

[Rodrigo C. <rc...@gm...>]

Also whats the difference btwn getSize and getCapacity?

On 8/24/06, Alexandre Moreira <ale...@gm...> wrote:
>
> 2006/8/24, Rodrigo Coacci <rc...@gm...>:
> [...]
> > When needed or if possible?
> > I guess I didn`t catch up that one.... Or you wrap around when needed o=
r
> > not....
> > What you do when it need but you can`t? Exception? Data loss?
> >
> The Buffer, as a class outside of our system, when need to put data
> and can't find any room for it, will throw an exception. It is the job
> of the client class (our system, in this context) to get a buffer that
> is large enough for the data it wants to put there (in our case this
> will probably be "Two times the size of the larger message", but I
> will explain the why later).
>
> [...]
>
> Regards,
> Alexandre Moreira.
>
> -------------------------------------------------------------------------
> 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 Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Nutshell-devel mailing list
> Nut...@li...
> https://lists.sourceforge.net/lists/listinfo/nutshell-devel
>



--=20
Abra=E7os,
      Rodrigo

Re: [Nutshell-devel] Basic class information : Byte Arrays

[Rodrigo C. <rc...@gm...>]

>
> ByteArray is an abstract class, it has a few methods implemented, but
> cannot be instantiated.
> what it does is to give a common interface to access things that wraps a
> byte array (char *). This can be used to aid in the serialization of many
> data types.
>
> ByteArray
> public:
>  const char& operator[](int index) const;
>  char& operator[](int index);
>  int getCapacity();
>  void copyFrom(const ByteArray& source, int srcIndex, int dstIndex, int
> size);
> private:
>  char& fetchCharacter(int index); // a wrapper to common functionality
> shared
>                                   // by both [] operators.
>  ByteArray(char * wrappedData, int capacity);
>

Wait a moment, this constructor is really to be private?
OTOH I don't see a default constructor (as this one is private), did you
miss this or was intentional?

 virtual ~ByteArray();
> protected:
>  int capacity;
>  char* data;
> --
>
>
--=20
Abra=E7os,
      Rodrigo

Re: [Nutshell-devel] Basic class information : Byte Buffer.

[Alexandre M. <ale...@gm...>]

2006/8/24, Rodrigo Coacci <rc...@gm...>:
[...]
> When needed or if possible?
> I guess I didn`t catch up that one.... Or you wrap around when needed or
> not....
> What you do when it need but you can`t? Exception? Data loss?
>
The Buffer, as a class outside of our system, when need to put data
and can't find any room for it, will throw an exception. It is the job
of the client class (our system, in this context) to get a buffer that
is large enough for the data it wants to put there (in our case this
will probably be "Two times the size of the larger message", but I
will explain the why later).

[...]

Regards,
Alexandre Moreira.

Re: [Nutshell-devel] Basic class information : Byte Buffer.

[Rodrigo C. <rc...@gm...>]

On 8/24/06, Alexandre Moreira <ale...@gm...> wrote:
>
> Keeping the batch of messages related to the class of the system.
>
> A ByteBuffer is a buffer used by the network pieces of our system, to
> keep track of incoming data until it can safely extract a message out
> of it. Here is its basic definition (somethings may vary as I already
> have an implemented version of this class at home, with no access to
> it right now).
>
> The ByteBuffer is a circular buffer, that can hold up to size bytes,

 wrapping around when needed, if possible.
>

When needed or if possible?
I guess I didn`t catch up that one.... Or you wrap around when needed or
not....
What you do when it need but you can`t? Exception? Data loss?

This is useful to hold
> received data and yet-to-send data. Heavily used by our sockets.



> ByteBuffer
> public:
> ByteBuffer(int size);
> virtual ~ByteBuffer();
> insert(const ByteArray& source, int size);
> fetch(ByteArray& dest, int size);
> discard(int size);
> consume(ByteArray& dest, int size); // this is simply a fetch();
> discard();
> int getSize();
> int getCapacity();
> private:
> char* data;
> int size;
> int position;
>
> And there goes another piece of our class strucutre... a lecture
> brought to you by Yago Warner!
>
> Until I find out I missed something again, I'll rest.. .and work a bit
> more.
>
> Regards,
> Alexandre Moreira.
>
> -------------------------------------------------------------------------
> 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 Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Nutshell-devel mailing list
> Nut...@li...
> https://lists.sourceforge.net/lists/listinfo/nutshell-devel
>



--=20
Abra=E7os,
      Rodrigo

[Nutshell-devel] Basic class information : Byte Buffer.

[Alexandre M. <ale...@gm...>]

Keeping the batch of messages related to the class of the system.

A ByteBuffer is a buffer used by the network pieces of our system, to
keep track of incoming data until it can safely extract a message out
of it. Here is its basic definition (somethings may vary as I already
have an implemented version of this class at home, with no access to
it right now).

The ByteBuffer is a circular buffer, that can hold up to size bytes,
wrapping around when needed, if possible. This is useful to hold
received data and yet-to-send data. Heavily used by our sockets.

ByteBuffer
 public:
  ByteBuffer(int size);
  virtual ~ByteBuffer();
  insert(const ByteArray& source, int size);
  fetch(ByteArray& dest, int size);
  discard(int size);
  consume(ByteArray& dest, int size); // this is simply a fetch(); discard();
  int getSize();
  int getCapacity();
 private:
  char* data;
  int size;
  int position;

And there goes another piece of our class strucutre... a lecture
brought to you by Yago Warner!

Until I find out I missed something again, I'll rest.. .and work a bit more.

Regards,
Alexandre Moreira.

Re: [Nutshell-devel] Basic class information : Byte Arrays

[Alexandre M. <ale...@gm...>]

Answering my own message. damn I hate to forget things.

2006/8/24, Alexandre Moreira <ale...@gm...>:
[...]
>
> ByteArray
> public:
>  const char& operator[](int index) const;
>  char& operator[](int index);
>  int getCapacity();
>  void copyFrom(const ByteArray& source, int srcIndex, int dstIndex, int size);

char * getBackingArray() //returns a pointer to the array being used
as back-end.

>
> private:
>  char& fetchCharacter(int index); // a wrapper to common functionality shared
>                                   // by both [] operators.
>  ByteArray(char * wrappedData, int capacity);
>  virtual ~ByteArray();
> protected:
>  int capacity;
>  char* data;
> --
>
[...]

[Nutshell-devel] Basic class information : Byte Arrays

[Alexandre M. <ale...@gm...>]

As requested by Coacci, posting the description of the basic classes
involved in network code.

ByteArray is an abstract class, it has a few methods implemented, but cannot
be instantiated.
what it does is to give a common interface to access things that wraps a
byte array (char *). This can be used to aid in the serialization of many
data types.

ByteArray
public:
 const char& operator[](int index) const;
 char& operator[](int index);
 int getCapacity();
 void copyFrom(const ByteArray& source, int srcIndex, int dstIndex, int
size);
private:
 char& fetchCharacter(int index); // a wrapper to common functionality
shared
                                  // by both [] operators.
 ByteArray(char * wrappedData, int capacity);
 virtual ~ByteArray();
protected:
 int capacity;
 char* data;
--

With ByteArray as a basis, we can start creating wrappers for many things.

There is a class of information that can be wrapped in byte arrays for easy
serialization: all those "integer-based" types (char, short, int, unsigned
char, unsigned short, unsigned int, void* and fixed-point (which I will
explain later)). To aid those in serialization, we use a basic template
class that can make them, it is ByteArrayTemplateWrapper.

template <class T>
ByteArrayTemplateWrapper extends ByteArray as public
 public:
  ByteArrayTemplateWrapper(const T wrappedData);
  ~ByteArrayTemplateWrapper();
  const T& getValue();
  void setValue(const T&);
 private:
  T internalData;

Well, what it does:
 It receives a pointer to an entity of the T Type, and initialize its parent
ByteArray with a pointer to it (converted to char*) as data and the
sizeof(T) value as capacity. That effectively creates an serialized array of
the data described by the object.

WARNING: One should not use this template to serialize data that holds
pointers or stuff like that when sending through the network, as it
obviously would make no sense to the other end of the connection.

The ByteArrayTemplateWrapper is realized through a few typedefs, as follows:

typedef ByteArrayTemplateWrapper<int> ByteArrayIntWrapper;
typedef ByteArrayTemplateWrapper<short> ByteArrayShortWrapper;
typedef ByteArrayTemplateWrapper<char> ByteArrayCharWrapper;
typedef ByteArrayTemplateWrapper<void*> ByteArrayVoidPtrWrapper;
typedef ByteArrayTemplateWrapper<unsigned int> ByteArrayUnsignedIntWrapper;
typedef ByteArrayTemplateWrapper<unsigned short>
ByteArrayUnsignedShortWrapper;
typedef ByteArrayTemplateWrapper<unsigned char>
ByteArrayUnsignedCharWrapper;

These are commonly used to handle the information packed into a message's
body.

--

Along with the TemplateWrappers there is also an "Allocated Array Wrapper",
that just creates an array of chars from heap space and holds its pointer
until it is destructed (be it by scope ending or explicit delete). It
follows:

AllocByteArray extends ByteArray as public
 public:
  AllocByteArray(int capacity);
  AllocByteArray(char* source, int size);
  ~AllocByteArray();

And that is pretty much it. The constructors are simple, one just allocates
it, the other allocates and copies the data from the source array to the
newly allocated one.



Well, I just hope this is enough information for you to start the UML class
diagrams, Coacci. I have to work a bit now, otherwise my boss will get mad
at me (lol).

Cheers,
Alexandre Moreira.

Re: [Nutshell-devel] Welcome.

[Reinaldo L. <li...@gm...>]

And this is the stupid message to thank the guy who gave the project its
birth.

To discover the status of Nutshell as a living entity, apply thermodynamics.

Salute,
Reinaldo Litaiff

On 8/24/06, Alexandre Moreira <ale...@gm...> wrote:
>
> Just a stupid message to welcome the guy who gave the project its name:
>
> Welcome, Litaiff, to our almost-dead (or would it be almost-living?)
> community.
>
> Cheers,
> Alexandre Moreira.
>
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> Nutshell-devel mailing list
> Nut...@li...
> https://lists.sourceforge.net/lists/listinfo/nutshell-devel
>

[Nutshell-devel] Welcome.

[Alexandre M. <ale...@gm...>]

Just a stupid message to welcome the guy who gave the project its name:

Welcome, Litaiff, to our almost-dead (or would it be almost-living?) community.

Cheers,
Alexandre Moreira.

[Nutshell-devel] Wiki usage.

[Alexandre M. <ale...@gm...>]

Hey there, Coacci.

I just noticed your message at the wiki and I think we should keep the
wiki to post ideas... and discuss them on the mailing lists... what
you say ? :P

Re: [Nutshell-devel] GPL

[Alexandre M. <ale...@gm...>]

Actually I gave it up on non-GPL nutshell, for I realized I had not
the time to do it on my own. Perhaps someone with fresher Ideas and
better time than I can help it go on.

by the way, I know we are only the both of us in this mail list yet,
and that we both speak portuguese but, as we are being "watched" by
the mail-list archive, we better stick to the List supported language,
so everyone can read the past discussions.

Regards,
Alexandre Moreira.

2006/7/26, Rodrigo Coacci <rc...@gm...>:
> Eu achei que vc nao queria fazer o nutshell GPL.... Desisitu? ou o SF ago=
ra
> aceita projetos nao GPL?
>
>
> --
> Abra=E7os,
>       Rodrigo
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
>
> _______________________________________________
> Nutshell-devel mailing list
> Nut...@li...
> https://lists.sourceforge.net/lists/listinfo/nutshell-devel
>
>
>

[Nutshell-devel] GPL

[Rodrigo C. <rc...@gm...>]

Eu achei que vc nao queria fazer o nutshell GPL.... Desisitu? ou o SF agora
aceita projetos nao GPL?


--=20
Abra=E7os,
      Rodrigo

Re: [Nutshell-devel] Test

[Alexandre M. <ale...@gm...>]

Pong

--
Abra=E7os,
        Alexandre Moreira.

2006/7/25, Rodrigo Coacci <rc...@gm...>:
> Ping
>
> --
> Abra=E7os,
>       Rodrigo
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
>
> _______________________________________________
> Nutshell-devel mailing list
> Nut...@li...
> https://lists.sourceforge.net/lists/listinfo/nutshell-devel
>
>
>

[Nutshell-devel] Test

[Rodrigo C. <rc...@gm...>]

Ping

--=20
Abra=E7os,
      Rodrigo