Sebastian Kuzminsky wrote:
> --- nml.cc2008/04/27 01:43:50 1.18
> +++ nml.cc2008/11/21 02:59:48 1.19
> @@ -68,6 +68,7 @@
> {
> if (cfg_file == NULL) {
> default_nml_config_file = NULL;
> +return;
> }
> default_nml_config_file = (char *) malloc(strlen(cf
Chris Morley wrote:
>
>
> > From: [EMAIL PROTECTED]
> > To: emc-developers@lists.sourceforge.net
> > Date: Thu, 20 Nov 2008 23:26:42 +
> > Subject: Re: [Emc-developers] Controlling EMC from a non-GPL application
> >
> > On Thursday 20 November 2008, Leslie Newell wrote:
> > > When the EMC2 proj
On Fri, Nov 21, 2008 at 12:40:08AM +, Chris Morley wrote:
>
> I find it interesting and important that
> everyone know the overal ideology.
This is a tough question because there is no "overall" ideology.
There may or may not be a "prevalent" ideology.
The EMC project is at least on its se
On Thu, Nov 20, 2008 at 11:26:42PM +, paul_c wrote:
> Then there are a few files that contain problematic phrases.. i.e.:
>
> //This is a generated file; the "corresponding source code" is the set of
> //files used by Altera's Quartus software to generate an .rbf-format
> //fpga fi
> From: [EMAIL PROTECTED]> To: emc-developers@lists.sourceforge.net> Date: Thu,
> 20 Nov 2008 23:26:42 +> Subject: Re: [Emc-developers] Controlling EMC
> from a non-GPL application> > On Thursday 20 November 2008, Leslie Newell
> wrote:> > When the EMC2 project was started the EMC developer
On Thursday 20 November 2008, Leslie Newell wrote:
> When the EMC2 project was started the EMC developers applied the GPL2
> license to most of the original code to prevent this happening in the
> future.
At the time, concerns were raised over the validity of the exercise - Duly
ignored..
Now
If you modify GPLed code you have to make the modified code publicly
available. If you write a program that contains GPLed code you are
required to make all of your program open source. Even if you use a few
definitions out of one GPLed header file the whole of your code has to
be open source.
> > 2) Convince the authors of the affected header files to change the
> > license to LGPL. The source files can still be GPL2 with LGPL headers.
> > This has a number of political considerations and affects quite a few
> > header files.
In layman's terms what is the difference and why one over
Hi Paul,
> Not gonna happen - Anyone who questions the validity of (L)GPL status is
> dismissed as a "troll".
>
IMHO, this would be a good candidate for LGPL but if the powers that be
say no, then I just have to live with it.
> Or you could use Tcl/Tk.
>
Wouldn't that still be linking
On Thu, Nov 20, 2008 at 04:22:05PM +, paul_c wrote:
>
> RCSlib is public domain, as is EMC[1]. You will find the relevant data
> structures have had additions made, but I see no reason why you couldn't pad
> out the originals in order to realign the required fields.
This is true.
> How muc
Les,
I don't think the time to parse is much of an issue, because even an
inefficient parser is going to execute orders of magnitude faster than the
transmission time over Ethernet.
Regards,
Eric
To be honest, I was thinking more of the overhead in parsing the text either
end than efficient net
On Thursday 20 November 2008, Leslie Newell wrote:
> 1) Looking closer, RCSlib is LGPL so I can safely use it. However the
> header files that define the data types are GPL2 which means I can't use
> them directly. Assuming the data types haven't changed since EMC1 then I
> could use the public dom
Steve,
Yes, you are correct there, but even the loopback socket seems to have some
non-trivial overhead, like on the order of 1ms. For a parser to parse a
single line of text (less than one packet size), as we are discussing here,
even 1ms is an eternity on most processors usable by EMC2.
I also
Eric H. Johnson wrote:
>Les,
>
>I don't think the time to parse is much of an issue, because even an
>inefficient parser is going to execute orders of magnitude faster than the
>transmission time over Ethernet.
>
>
Err - there's no particular need to actuall y transfer packets over
ethernet, is
Thanks Eric,
To be honest, I was thinking more of the overhead in parsing the text
either end than efficient network transfer. Presumably if I am using
local sockets then the packet size isn't an issue. I envisage most users
having SheetCam and EMC on the same machine. I will experiment with
emcr
Les,
FYI, there is already a hook in emcrsh for a binary equivalent protocol, but
I have so far not needed to implement it. There are several networking
issues, and I do not claim to be an expert in networking, however, as I
understand it, a standard 10 Base T / 100 Base T Ethernet packet is
appro
Hi Paul,
> Not much in the way of documentation, but then the API is simple to use.
> Probably http://www.isd.mel.nist.gov/projects/rcslib/NMLcpp.html is the most
> useful guide.
>
> Contact me off list (or by phone) if you need any help in that area.
>
Thanks. I may take you up on that offe
As far as I can see there are a number of options:
1) Looking closer, RCSlib is LGPL so I can safely use it. However the
header files that define the data types are GPL2 which means I can't use
them directly. Assuming the data types haven't changed since EMC1 then I
could use the public domain EMC
Hi Les
On Wednesday 19 November 2008, Leslie Newell wrote:
> So if I stick to using NML and RCS then I can talk directly to EMC? Are
> there any docs on this side of things?
Not much in the way of documentation, but then the API is simple to use.
Probably http://www.isd.mel.nist.gov/projects/rc
On Wednesday 19 November 2008, Jeff Epler wrote:
> Paul, because you are the former developer
Who the **&* are you to decide who is or isn't a "developer" ?
-
This SF.Net email is sponsored by the Moblin Your Move Developer
20 matches
Mail list logo
