Hello everyone!
My name is Charles Tilbury and I currently reside in Portland, Oregon, USA. I have been working on developing my own language for several months now, only to discover that Pike is almost exactly what I was trying to make! I only wish I had found out about it earlier.
I need a fast interpreted language with GUI support for Unix, Windows, and Mac/OS. I am planning to make commercial applications in the area of EDA and embedded software developement tools such as JTAG debuggers. I want to use a GUI compatability suite such as wxWindows to allow portability to my chosen platforms.
If I use Pike, I will write the wxWindows/Pike binding and release it under the Pike licensing scheme, but I will probably arrange to encrypt the pike scripts that are part of my applications.
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that: 1. The maintainers of Pike are at least not against a project like this. 2. That if I decide to write books about Pike and/or the wxWindows binding to it, that no one has any real objection to it.
I would be very interested in hearing your comments.
Highest Regards, Charles Tilbury
Sounds like an interesting project.
I don't think any of the maintainers have anything against someone writing a wxWindow module. Were you planning on it being released into the main Pike branch?
I'm sure noone at all have anything against books on the subject. :)
/ Mirar
Previous text:
2003-05-16 22:38: Subject: introduce myself
Hello everyone!
My name is Charles Tilbury and I currently reside in Portland, Oregon, USA. I have been working on developing my own language for several months now, only to discover that Pike is almost exactly what I was trying to make! I only wish I had found out about it earlier.
I need a fast interpreted language with GUI support for Unix, Windows, and Mac/OS. I am planning to make commercial applications in the area of EDA and embedded software developement tools such as JTAG debuggers. I want to use a GUI compatability suite such as wxWindows to allow portability to my chosen platforms.
If I use Pike, I will write the wxWindows/Pike binding and release it under the Pike licensing scheme, but I will probably arrange to encrypt the pike scripts that are part of my applications.
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that:
- The maintainers of Pike are at least not against a project like this.
- That if I decide to write books about Pike and/or the wxWindows binding to
it, that no one has any real objection to it.
I would be very interested in hearing your comments.
Highest Regards, Charles Tilbury
/ Brevbäraren
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that:
- The maintainers of Pike are at least not against a project like this.
Speaking only for myself I can say that this most definitely would be a good thing. Another GUI backend is never a bad thing. As for encrypted or somehow protected source files - that's a nice feature too. Question is how to handle it in a way that actually gives real security, rather than obfuscation level security. That said, the ability to distribute closed source (or unreadable source) apps with Pike is something I have been wanting to see for a long time.
- That if I decide to write books about Pike and/or the wxWindows binding to it, that no one has any real objection to it.
I can assure you that everyone here wants to see many books written about Pike, be they general or specific to certain needs. In the past several attempts have been made to get something going but it never has happened.
/ David Hedbor
Previous text:
2003-05-16 22:38: Subject: introduce myself
Hello everyone!
My name is Charles Tilbury and I currently reside in Portland, Oregon, USA. I have been working on developing my own language for several months now, only to discover that Pike is almost exactly what I was trying to make! I only wish I had found out about it earlier.
I need a fast interpreted language with GUI support for Unix, Windows, and Mac/OS. I am planning to make commercial applications in the area of EDA and embedded software developement tools such as JTAG debuggers. I want to use a GUI compatability suite such as wxWindows to allow portability to my chosen platforms.
If I use Pike, I will write the wxWindows/Pike binding and release it under the Pike licensing scheme, but I will probably arrange to encrypt the pike scripts that are part of my applications.
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that:
- The maintainers of Pike are at least not against a project like this.
- That if I decide to write books about Pike and/or the wxWindows binding to
it, that no one has any real objection to it.
I would be very interested in hearing your comments.
Highest Regards, Charles Tilbury
/ Brevbäraren
On Fri, May 16, 2003 at 10:50:02PM +0200, David Hedbor @ Pike developers forum wrote:
ability to distribute closed source (or unreadable source) apps with Pike is something I have been wanting to see for a long time.
Isn't possible to do it now? If it is possible to (pre-)compile Pike modules, why not to make this feature (module compilation) standard one? Are there some problems or?
Regarfs, /Al
I was thinking more along the lines of PGP with both keys being private.
On Fri, 2003-05-16 at 18:52, Alexander Demenshin wrote:
On Fri, May 16, 2003 at 10:50:02PM +0200, David Hedbor @ Pike developers forum wrote:
ability to distribute closed source (or unreadable source) apps with Pike is something I have been wanting to see for a long time.
Isn't possible to do it now? If it is possible to (pre-)compile Pike modules, why not to make this feature (module compilation) standard one? Are there some problems or?
Regarfs, /Al
On Fri, May 16, 2003 at 07:42:30PM -0700, Charles Tilbury wrote:
I was thinking more along the lines of PGP with both keys being private.
How? The interpreter needs to decrypt the source, once it is done it may be captured, or the key may be extracted from the interpreter binary, etc. (it is like how DVDs encryption may be avoided, not cracked).
In general, you cannot use encryption to keep your source hidden (unless you have some hardware-based interpreter, but even then...), it will only slow down reverse engineering, just a bit. But finally the attacker will get the source code as is (the original).
However, in case when you use a byte code there is no way to convert it to original source, so it is preffered way to keep source closed (it is also quite difficult to modify or tweak byte-code for an attacker, since it requires deep knowledge of the interpreter, VM and program logic).
Regards, /Al
Al,
On Fri, 2003-05-16 at 20:03, Alexander Demenshin wrote:
On Fri, May 16, 2003 at 07:42:30PM -0700, Charles Tilbury wrote:
I was thinking more along the lines of PGP with both keys being private.
Maybe an outstanding idea, eh? <<grin>>
How? The interpreter needs to decrypt the source, once it is done it may be captured, or the key may be extracted from the interpreter binary, etc. (it is like how DVDs encryption may be avoided, not cracked).
The way I understand the LGPL, it is OK to distribute a proprietary binary. You just cannot prevent others from receiving the original, unmodified source code. Do you agree?
In general, you cannot use encryption to keep your source hidden (unless you have some hardware-based interpreter, but even then...), it will only slow down reverse engineering, just a bit. But finally the attacker will get the source code as is (the original).
True; nothing can stop a dedicated hacker. The best you can hope for is to help the honest people avoid temptation. The other side of that is that if everyone is hacking you or using a hacked version, then you are probably charging too much.
However, in case when you use a byte code there is no way to convert it to original source, so it is preffered way to keep source closed (it is also quite difficult to modify or tweak byte-code for an attacker, since it requires deep knowledge of the interpreter, VM and program logic).
The would-be-hacker would have the source code for the VM, wouldn't he? It is amazing what some people can do by tweaking a byte or two. <<g>>
Thanks, Charles T.
Regards, /Al
On Fri, May 16, 2003 at 09:34:45PM -0700, Charles Tilbury wrote:
The way I understand the LGPL, it is OK to distribute a proprietary binary. You just cannot prevent others from receiving the original, unmodified source code. Do you agree?
Well, actually I am talking about distributing binary code only, without providing access to the source code :) You may argue, but sometimes this is necessary (as you say - "to help the honest people avoid temptation" :).
that if everyone is hacking you or using a hacked version, then you are probably charging too much.
Well, there are some cases when people hack just for fun, so... And in general, I don't care if 10%-20% will hack while other 90-80% will pay :)
The would-be-hacker would have the source code for the VM, wouldn't he?
Sure he would, but he will need time and resources to learn and understand it, the he will need even more time to study generated byte-code, so... it may help to stop some undedicated (or even partially dedicated) hackers :)
Regards, /Al
Sure he would, but he will need time and resources to learn and understand it, the he will need even more time to study generated byte-code, so... it may help to stop some undedicated (or even partially dedicated) hackers :)
I believe that encryption would accomplish the same thing. Just mentioning the word scares the clueless. <<g>>
</CT>
On Fri, May 16, 2003 at 10:04:15PM -0700, Charles Tilbury wrote:
I believe that encryption would accomplish the same thing. Just mentioning the word scares the clueless. <<g>>
Absolutely. But only clueless, while I would like to scare a bit more knowledgeable and experienced :)
Regards, /Al
what about making pike optionally produce CIL (Common Intermediate Language) which can then be run/compiled with the tools from the mono project? (go-mono.com) their JIT is quite good, AFAIK.
/ karl
That could be interesting. How hard it'd be depends on how well its runtime matches pike behavior. How does it compare to the Java VM? That has been around longer and should have some good compilers by now.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-17 20:46: Subject: Re: source encryption
what about making pike optionally produce CIL (Common Intermediate Language) which can then be run/compiled with the tools from the mono project? (go-mono.com) their JIT is quite good, AFAIK.
/ karl
/ Brevbäraren
On Sat, 2003-05-17 at 21:15, Martin Stjernholm wrote:
That could be interesting. How hard it'd be depends on how well its runtime matches pike behavior.
huh. i have no idea of the pike internals :-) though i guess it will not be very 'compatible'.
could someone please post a overview how pike vm/interpreter/code generator works?
from the mono site:
<quote uri="http://www.go-mono.com/runtime.html"> The JIT engine uses a code-generator generator approach for compilation. Given the properties of CIL byte codes, we can take full advantage of a real instruction selector for our code generator.
The JIT engine implements a number of optimizations:
Opcode cost estimates (our architecture allows us to generate different code paths depending on the target CPU dynamically). Inlining. Constant folding.
Although compilers typically do constant folding, the combination of inlining with constant folding gives some very good results.
Linear scan register allocation. In the past, register allocation was our achilles heel, but now we have left this problem behind. </quote>
How does it compare to the Java VM? That has been around longer and should have some good compilers by now.
well, i imagined the simple way, as to let the pike compiler produce not pike byte code for execution in the pike interpreter but generate CIL instead.
also, the compiler is not the weak point i think, but the runtime engine.
/ karl
well, i imagined the simple way, as to let the pike compiler produce not pike byte code for execution in the pike interpreter but generate CIL instead.
So I gathered. If we're going to go through the trouble of adapting the pike core to a third party VM, we should consider well established ones like the Java VM. Maybe I've missed something - would it somehow be considerably easier to replace the Pike VM with CIL instead of JVM?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-17 22:09: Subject: pike and CIL/mono (was Re: source encryption)
On Sat, 2003-05-17 at 21:15, Martin Stjernholm wrote:
That could be interesting. How hard it'd be depends on how well its runtime matches pike behavior.
huh. i have no idea of the pike internals :-) though i guess it will not be very 'compatible'.
could someone please post a overview how pike vm/interpreter/code generator works?
from the mono site:
<quote uri="http://www.go-mono.com/runtime.html"> The JIT engine uses a code-generator generator approach for compilation. Given the properties of CIL byte codes, we can take full advantage of a real instruction selector for our code generator.
The JIT engine implements a number of optimizations:
Opcode cost estimates (our architecture allows us to generate different code paths depending on the target CPU dynamically). Inlining. Constant folding.
Although compilers typically do constant folding, the combination of inlining with constant folding gives some very good results.
Linear scan register allocation. In the past, register allocation was our achilles heel, but now we have left this problem behind.
</quote>
How does it compare to the Java VM? That has been around longer and should have some good compilers by now.
well, i imagined the simple way, as to let the pike compiler produce not pike byte code for execution in the pike interpreter but generate CIL instead.
also, the compiler is not the weak point i think, but the runtime engine.
/ karl
/ Brevbäraren
well, looking at the pike interpreter code and the new mono jitter called mini, i discover lots of similarities, but the code in mini is _lots_ cleaner, and both seem to follow similar concepts.
the mini jit also abstracts both front and backend, it could be entirely possible to make the mono jit execute pike internal opcodes.
(but i know nothing about interpreters/compilers :-)
question: wouldn't it safe some memory if the internal struct{}'s were packed and alinged? gcc does this with __attribute(pack) or so.
/ karl
the mini jit also abstracts both front and backend, it could be entirely possible to make the mono jit execute pike internal opcodes.
Aha, that's what I missed. Then it's suddenly a whole lot simpler. How would it work integration-wise? Would we have to rip out a lot of source from CIL, or is it some kind of yacc-like tool which eats a VM/opcode spec and spits out a custom VM?
question: wouldn't it safe some memory if the internal struct{}'s were packed and alinged? gcc does this with __attribute(pack) or so.
They are aligned by default. That's the idea at least. Packing them would perhaps save a bit of memory but at the expense of cpu cycles, and memory is typically a less precious resource than cpu time.
In many places the order and sizes are chosen specifically to get both packing and alignment. E.g. in the svalue struct:
struct svalue { unsigned INT16 type; unsigned INT16 subtype; union anything u; };
On a typical 32 bit architecture this takes two 4-byte words: type and subtype shares the first and the other holds the union (which is an integer, float or a pointer to something). If the compiler doesn't pack this by default it probably has a good reason for it.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-17 22:40: Subject: Re: pike and CIL/mono (was Re: source encryption)
well, looking at the pike interpreter code and the new mono jitter called mini, i discover lots of similarities, but the code in mini is _lots_ cleaner, and both seem to follow similar concepts.
the mini jit also abstracts both front and backend, it could be entirely possible to make the mono jit execute pike internal opcodes.
(but i know nothing about interpreters/compilers :-)
question: wouldn't it safe some memory if the internal struct{}'s were packed and alinged? gcc does this with __attribute(pack) or so.
/ karl
/ Brevbäraren
On Sat, 2003-05-17 at 23:00, Martin Stjernholm wrote:
the mini jit also abstracts both front and backend, it could be entirely possible to make the mono jit execute pike internal opcodes.
Aha, that's what I missed. Then it's suddenly a whole lot simpler. How would it work integration-wise? Would we have to rip out a lot of source from CIL, or is it some kind of yacc-like tool which eats a VM/opcode spec and spits out a custom VM?
the CIL seems to be defined in some XML and transformed to a c-macro definition file via XSL, which is then included in the interpreter. (in ./mono/cil/)
question: wouldn't it safe some memory if the internal struct{}'s were packed and alinged? gcc does this with __attribute(pack) or so.
They are aligned by default. That's the idea at least. Packing them would perhaps save a bit of memory but at the expense of cpu cycles, and memory is typically a less precious resource than cpu time.
In many places the order and sizes are chosen specifically to get both packing and alignment. E.g. in the svalue struct:
struct svalue { unsigned INT16 type; unsigned INT16 subtype; union anything u; };On a typical 32 bit architecture this takes two 4-byte words: type and subtype shares the first and the other holds the union (which is an integer, float or a pointer to something). If the compiler doesn't pack this by default it probably has a good reason for it.
allright, i see. thx for the enlightenment.
/ karl
Hello,
<puts on his asbestos suit>
I believe there is a pike-like language that runs on the mono JIT with excellent compiler and runtime support. It's called C#.
Why then try to turn a good language that has its niche and users into a half-baked copy of something else?
Because the mountain (of work) is there?
Regards,
Peter.
---
'God-like aliens - man, do I hate god-like aliens. I'll trade a critter for a god-like alien any day.' - John Crichton, Meltdown
On Tue, May 20, 2003 at 01:13:52AM +0200, Peter M. Lemmen wrote:
<puts on his asbestos suit>
you'll need that.
I believe there is a pike-like language that runs on the mono JIT with excellent compiler and runtime support. It's called C#.
what exactly makes c# pike-like?
Why then try to turn a good language that has its niche and users into a half-baked copy of something else?
huh? which is the half-baked copy? and which is the good language?
Because the mountain (of work) is there?
99% of the people fight for 90% of the available work. i prefer to be with the 1% of people who can choose from 10% of the work that noone wants to do.
greetings, martin.
what exactly makes c# pike-like?
Hard to say really. What makes pike similar to java?
At a quick glance, C# looks a lot like C++ and pike. There are, however, not too subtle differences (e.g. in object initialization).
BUT, they sure do look a lot like each other and it isn't that hard to go from one language to another. I belive the biggest hurdle is that pike has a lot more syntactic sugar on top of it.
/ Peter Lundqvist (disjunkt)
Previous text:
2003-05-20 01:29: Subject: Re: pike and CIL/mono
On Tue, May 20, 2003 at 01:13:52AM +0200, Peter M. Lemmen wrote:
<puts on his asbestos suit>
you'll need that.
I believe there is a pike-like language that runs on the mono JIT with excellent compiler and runtime support. It's called C#.
what exactly makes c# pike-like?
Why then try to turn a good language that has its niche and users into a half-baked copy of something else?
huh? which is the half-baked copy? and which is the good language?
Because the mountain (of work) is there?
99% of the people fight for 90% of the available work. i prefer to be with the 1% of people who can choose from 10% of the work that noone wants to do.
greetings, martin.
Pike Conference 2003 - Sep 25-27 - http://pike.ida.liu.se/conferences/2003/
interested in doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer working in europe open-steam.org unix system- bahai.or.at iaeste.(tuwien.ac|or).at administrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
<puts on his asbestos suit>
*grin* Glad too see that you get the gist of things... ;-)
I believe there is a pike-like language that runs on the mono JIT with excellent compiler and runtime support. It's called C#.
Why then try to turn a good language that has its niche and users into a half-baked copy of something else?
Well, I see your point. In fact it's painfully clear seen from a single language's perspective. However - if one looks at it from a mor abstract level - there is allways the possibility to share code with other languages written for CIL (I'm not sure if this is at .NET level or not, but I don't think so). That is, the pike code may use code from other projects (C#, VB, whatever) and vice versa.
I belive there are some difficulties in achieving this, but the runtime environment was designed to be able to share code between supported languages.
/ Peter Lundqvist (disjunkt)
Previous text:
2003-05-20 01:14: Subject: RE: pike and CIL/mono
Hello,
<puts on his asbestos suit>
I believe there is a pike-like language that runs on the mono JIT with excellent compiler and runtime support. It's called C#.
Why then try to turn a good language that has its niche and users into a half-baked copy of something else?
Because the mountain (of work) is there?
Regards,
Peter.
'God-like aliens - man, do I hate god-like aliens. I'll trade a critter for a god-like alien any day.'
- John Crichton, Meltdown
/ Brevbäraren
but the thing that distinguishes pike from other languages is not the syntax but the runtime. mono.net while allowing differences in syntax all share a common runtime.
if you drop pikes runtime, most of its power will be lost.
greetings, martin.
On Tue, 2003-05-20 at 01:43, Martin Baehr wrote:
but the thing that distinguishes pike from other languages is not the syntax but the runtime. mono.net while allowing differences in syntax all share a common runtime.
if you drop pikes runtime, most of its power will be lost.
well, my initial proposal/idea was, that CIL code could be produces _optionally_, for example to distribute compiled versions of pike programs.
i do not insist on such CIL interface, also compiled/precompiled pike would be fine, and it should be embeddeable.
i also naively imagined mono and pike developers which, by all means, are both skilled pretty good, pull on the same stings as a side effect.
/ karl
Hello,
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se]On Behalf Of Martin Baehr Sent: dinsdag 20 mei 2003 01:44 To: Peter Lundqvist (disjunkt) @ Pike (-) developers forum Cc: pike-devel@lists.lysator.liu.se Subject: Re: pike and CIL/mono
but the thing that distinguishes pike from other languages is not the syntax but the runtime. mono.net while allowing differences in syntax all share a common runtime.
if you drop pikes runtime, most of its power will be lost.
greetings, martin.
My point exactly, making a CIL compiler for Pike will turn pike into just another Dialect of C# (Like VB.NET and Perl.NET). A little syntactic sugar coating of exactly the same functionality as all the others.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se]On Behalf Of Peter Lundqvist (disjunkt) @ Pike (-) developers forum Sent: dinsdag 20 mei 2003 01:30 To: pike-devel@lists.lysator.liu.se Subject: RE: pike and CIL/mono
<SNIP>
Well, I see your point. In fact it's painfully clear seen from a single language's perspective. However - if one looks at it from a mor abstract level - there is allways the possibility to share code with other languages written for CIL (I'm not sure if this is at .NET level or not, but I don't think so). That is, the pike code may use code from other projects (C#, VB, whatever) and vice versa.
I belive there are some difficulties in achieving this, but the runtime environment was designed to be able to share code between supported languages.
/ Peter Lundqvist (disjunkt)
I believe this is the wrong way of looking at the .NET Framework. You are not using a bit of VB in C# or a bit of Perl in Managed C++. You are just using CIL in more CIL. The actual syntax of VB or Perl doesn't add anything to the fact that it all get compiled to CIL.
Regards,
Peter.
---
'God-like aliens - man, do I hate god-like aliens. I'll trade a critter for a god-like alien any day.' - John Crichton, Meltdown
Dropping the pike runtime hasn't been proposed afaics. I agree that would make it pointless. I see CIL integration as a way to get better machine/byte code compiler/interpreter that we don't have to develop and maintain completely ourselves.
If it also added the benefit of getting access to the extensive .NET library then I absolutely wouldn't mind that at all. The bits I've seen of .NET have been well designed and have a consistency I can't help but admire.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-20 01:47: Subject: Re: pike and CIL/mono
but the thing that distinguishes pike from other languages is not the syntax but the runtime. mono.net while allowing differences in syntax all share a common runtime.
if you drop pikes runtime, most of its power will be lost.
greetings, martin.
/ Brevbäraren
Well, C# has some similarities to Pike, but that is about it. I would rather say it's a mix of Java and C/C++ since the syntax (IMHO at least) is very javaish.
Pike-people have, since long before anyone ever heard of C#, been discussing the fact that Pike would benefit from a compile/runtime separation. One solution to the problem would be the one that has been discussed here the last few days.
/ Marcus Agehall (Trådlös)
Previous text:
2003-05-20 01:14: Subject: RE: pike and CIL/mono
Hello,
<puts on his asbestos suit>
I believe there is a pike-like language that runs on the mono JIT with excellent compiler and runtime support. It's called C#.
Why then try to turn a good language that has its niche and users into a half-baked copy of something else?
Because the mountain (of work) is there?
Regards,
Peter.
'God-like aliens - man, do I hate god-like aliens. I'll trade a critter for a god-like alien any day.'
- John Crichton, Meltdown
/ Brevbäraren
Precompilation is very platform dependent and thus not a viable option unless you also ship with a precompiled binary of Pike for each platform. Imagine the pain in doing that. :)
/ David Hedbor
Previous text:
2003-05-17 03:53: Subject: Re: introduce myself
On Fri, May 16, 2003 at 10:50:02PM +0200, David Hedbor @ Pike developers forum wrote:
ability to distribute closed source (or unreadable source) apps with Pike is something I have been wanting to see for a long time.
Isn't possible to do it now? If it is possible to (pre-)compile Pike modules, why not to make this feature (module compilation) standard one? Are there some problems or?
Regarfs, /Al
/ Brevbäraren
No, that is not as big problem. For 7.2 the byte is platform independent, but with the introduction of native byte code 7.4 became platform dependent again. It still can handle the independent code though, so just export that (and take the performance penelty).
/ Martin Nilsson (lambda)
Previous text:
2003-05-17 12:10: Subject: Re: introduce myself
Precompilation is very platform dependent and thus not a viable option unless you also ship with a precompiled binary of Pike for each platform. Imagine the pain in doing that. :)
/ David Hedbor
Maybe you realize this and are only expressing yourself unclearly, but
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-05-17 13:24: Subject: Re: introduce myself
No, that is not as big problem. For 7.2 the byte is platform independent, but with the introduction of native byte code 7.4 became platform dependent again. It still can handle the independent code though, so just export that (and take the performance penelty).
/ Martin Nilsson (lambda)
It's also very pike version dependent; currently it checks the version down to the build number before accepting the byte compiled code. I'd like to change the dumped format so that it's platform independent and fairly pike version independent. I.e. make a somewhat more well defined virtual machine spec.
The dump format should also be more robust regarding identifier lookup etc. Currently, if a dumped program inherits some other program then the layout of the inherited program is hardcoded in the dump. That means that if identifiers are added, removed or moved around in the inherited program then the dumped program might generate errors, or even worse just use the wrong functions and variables in the inherited one.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-17 12:10: Subject: Re: introduce myself
Precompilation is very platform dependent and thus not a viable option unless you also ship with a precompiled binary of Pike for each platform. Imagine the pain in doing that. :)
/ David Hedbor
- The maintainers of Pike are at least not against a project like this.
Definitely not. If you want to contribute the wxWindows bindings to the main dist (something I'd really like as Win32-GTK is not that stable) take a look at http://pike.ida.liu.se/development/cvs/policies.xml
- That if I decide to write books about Pike and/or the wxWindows
binding to it, that no one has any real objection to it.
Knock yourself out and tell me where I can bye a copy.
/ Peter Bortas
Previous text:
2003-05-16 22:38: Subject: introduce myself
Hello everyone!
My name is Charles Tilbury and I currently reside in Portland, Oregon, USA. I have been working on developing my own language for several months now, only to discover that Pike is almost exactly what I was trying to make! I only wish I had found out about it earlier.
I need a fast interpreted language with GUI support for Unix, Windows, and Mac/OS. I am planning to make commercial applications in the area of EDA and embedded software developement tools such as JTAG debuggers. I want to use a GUI compatability suite such as wxWindows to allow portability to my chosen platforms.
If I use Pike, I will write the wxWindows/Pike binding and release it under the Pike licensing scheme, but I will probably arrange to encrypt the pike scripts that are part of my applications.
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that:
- The maintainers of Pike are at least not against a project like this.
- That if I decide to write books about Pike and/or the wxWindows binding to
it, that no one has any real objection to it.
I would be very interested in hearing your comments.
Highest Regards, Charles Tilbury
/ Brevbäraren
- That if I decide to write books about Pike and/or the wxWindows
binding to it, that no one has any real objection to it.
"I have a dream that one day Pike will rise up on O'Reilly bookshelves..."
(freely adapted from Martin Luther King, Jr)
/oliv3
=)
Has anyone ever started to draw up a plan on what such a book should contain? I guess that is the hard part...
/ Peter Lundqvist (disjunkt)
Previous text:
2003-05-17 01:27: Subject: Re: introduce myself
- That if I decide to write books about Pike and/or the wxWindows
binding to it, that no one has any real objection to it.
"I have a dream that one day Pike will rise up on O'Reilly bookshelves..."
(freely adapted from Martin Luther King, Jr)
/oliv3
-- "Une cause tres petite, qui nous echappe, determine un effet considerable que nous ne pouvons pas ne pas voir, et alors nous disons que cet effet est du au hasard." -- Poincare, in 'Science et Methode', 1908
/ Brevbäraren
On Fri, May 16, 2003 at 08:36:58PM +0000, charles.tilbury@attbi.com wrote:
- That if I decide to write books about Pike and/or the wxWindows
binding to it, that no one has any real objection to it.
objections? are you kidding?
where do i place my preorder? ;-)
greetings, martin.
but I will probably arrange to encrypt the pike scripts that are part of my applications.
I'll try to discourage you from doing that (or at least make you clarify what you want to achieve). Which of course doesn't mean that you can't do it if you really want to.
* Technically, it is not possible to do what you want: Everything needed to run the program must be distributed to the user's computer, which you don't trust. Including any needed decryption keys. It's just a matter of stubbornness to extract the keys.
* People interested in running or distributed unlicensed copies of the program (sometimes called "pirates") don't need to decrypt it. And technical tricks like dongles, license servers usually annoy your legitimate users, while being worked around by people that use the program without a license.
* As for people (competitors) copying parts of the *source* code for use in their own programs, without any license to do that. Is that a real problem? I've never seen anything like that during the few years I did proprietary software development. It sounds like a very dangerous thing to do. It get's *even* more dangerous if you use a programming environment (like Pike) where the source code is usually distributed to customers.
* For most software, paying customers aren't very interested in breaking your license. For instance, as far as I'm aware, Roxen never had any problems with "Roxen Platform"-customers that did things they weren't licensed to.
* Source availability can be useful for customers (even if it's a traditional proprietary license, no "free software" stuff), as it makes local patches and bug-fixes possible, for instance, as a part of a support issue.
Happy hacking, /Niels
/ Niels Möller (med röd bil)
Previous text:
2003-05-16 22:38: Subject: introduce myself
Hello everyone!
My name is Charles Tilbury and I currently reside in Portland, Oregon, USA. I have been working on developing my own language for several months now, only to discover that Pike is almost exactly what I was trying to make! I only wish I had found out about it earlier.
I need a fast interpreted language with GUI support for Unix, Windows, and Mac/OS. I am planning to make commercial applications in the area of EDA and embedded software developement tools such as JTAG debuggers. I want to use a GUI compatability suite such as wxWindows to allow portability to my chosen platforms.
If I use Pike, I will write the wxWindows/Pike binding and release it under the Pike licensing scheme, but I will probably arrange to encrypt the pike scripts that are part of my applications.
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that:
- The maintainers of Pike are at least not against a project like this.
- That if I decide to write books about Pike and/or the wxWindows binding to
it, that no one has any real objection to it.
I would be very interested in hearing your comments.
Highest Regards, Charles Tilbury
/ Brevbäraren
Niels,
On Sun, 2003-05-18 at 02:25, Niels Möller (med röd bil) @ Pike (-) developers forum wrote:
but I will probably arrange to encrypt the pike scripts that are part of my applications.
I'll try to discourage you from doing that (or at least make you clarify what you want to achieve). Which of course doesn't mean that you can't do it if you really want to.
I must say that this is the smallest of the issues that I am facing just now. The real issue is "how to map wxWindows C++ classes to Pike classes". I do not really want to write a C wrapper for the classes. <<grin>>
- Technically, it is not possible to do what you want: Everything needed to run the program must be distributed to the user's computer, which you don't trust. Including any needed decryption keys. It's just a matter of stubbornness to extract the keys.
All one may hope for is to slow down a dedicated hacker. Most people are not hackers and not many people who have sufficient knowledge to hack software are dedicated.
- People interested in running or distributed unlicensed copies of the program (sometimes called "pirates") don't need to decrypt it. And technical tricks like dongles, license servers usually annoy your legitimate users, while being worked around by people that use the program without a license.
I hate dongles.
- As for people (competitors) copying parts of the *source* code for use in their own programs, without any license to do that. Is that a real problem? I've never seen anything like that during the few years I did proprietary software development. It sounds like a very dangerous thing to do. It get's *even* more dangerous if you use a programming environment (like Pike) where the source code is usually distributed to customers.
In the final analysis, the only reason that a compeditor would steal from me would be to save time. There will not be anything patentable in this software.
- For most software, paying customers aren't very interested in breaking your license. For instance, as far as I'm aware, Roxen never had any problems with "Roxen Platform"-customers that did things they weren't licensed to.
They bought the licence so that someone else will fix bugs and provide enhansements.
- Source availability can be useful for customers (even if it's a traditional proprietary license, no "free software" stuff), as it makes local patches and bug-fixes possible, for instance, as a part of a support issue.
I use Visual Slick Edit (an excellent product) to edit text. It uses a C like macro language to implement the entire user interface. The source code for just about everything is provided with the package. Looking at that part of the product is just about the last thing that I want to do because of the time it would take.
Cheers, Charles T.
Happy hacking, /Niels
/ Niels Möller (med röd bil)
Previous text:
2003-05-16 22:38: Subject: introduce myself
Hello everyone!
My name is Charles Tilbury and I currently reside in Portland, Oregon, USA. I have been working on developing my own language for several months now, only to discover that Pike is almost exactly what I was trying to make! I only wish I had found out about it earlier.
I need a fast interpreted language with GUI support for Unix, Windows, and Mac/OS. I am planning to make commercial applications in the area of EDA and embedded software developement tools such as JTAG debuggers. I want to use a GUI compatability suite such as wxWindows to allow portability to my chosen platforms.
If I use Pike, I will write the wxWindows/Pike binding and release it under the Pike licensing scheme, but I will probably arrange to encrypt the pike scripts that are part of my applications.
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that:
- The maintainers of Pike are at least not against a project like this.
- That if I decide to write books about Pike and/or the wxWindows binding to
it, that no one has any real objection to it.
I would be very interested in hearing your comments.
Highest Regards, Charles Tilbury
/ Brevbäraren
I must say that this is the smallest of the issues that I am facing just now. The real issue is "how to map wxWindows C++ classes to Pike classes". I do not really want to write a C wrapper for the classes. <<grin>>
Glad to hear that, wxWindows support sounds a lot more useful ;-)
- As for people (competitors) copying parts of the *source* code for use in their own programs, without any license to do that. Is that a real problem?
In the final analysis, the only reason that a compeditor would steal from me would be to save time. There will not be anything patentable in this software.
Copying your code, without permission, will be a copyright violation, of the worst kind. About as criminal as a willful patent infringement. And there will always be some disgruntled employee who knows they copied your code, and could tell you about it. So to do that, they have to be either pretty sure they won't get caught, or pretty stupid.
/Niels
/ Niels Möller (med röd bil)
Previous text:
2003-05-18 22:04: Subject: Re: introduce myself
Niels,
On Sun, 2003-05-18 at 02:25, Niels Möller (med röd bil) @ Pike (-) developers forum wrote:
but I will probably arrange to encrypt the pike scripts that are part of my applications.
I'll try to discourage you from doing that (or at least make you clarify what you want to achieve). Which of course doesn't mean that you can't do it if you really want to.
I must say that this is the smallest of the issues that I am facing just now. The real issue is "how to map wxWindows C++ classes to Pike classes". I do not really want to write a C wrapper for the classes. <<grin>>
- Technically, it is not possible to do what you want: Everything needed to run the program must be distributed to the user's computer, which you don't trust. Including any needed decryption keys. It's just a matter of stubbornness to extract the keys.
All one may hope for is to slow down a dedicated hacker. Most people are not hackers and not many people who have sufficient knowledge to hack software are dedicated.
- People interested in running or distributed unlicensed copies of the program (sometimes called "pirates") don't need to decrypt it. And technical tricks like dongles, license servers usually annoy your legitimate users, while being worked around by people that use the program without a license.
I hate dongles.
- As for people (competitors) copying parts of the *source* code for use in their own programs, without any license to do that. Is that a real problem? I've never seen anything like that during the few years I did proprietary software development. It sounds like a very dangerous thing to do. It get's *even* more dangerous if you use a programming environment (like Pike) where the source code is usually distributed to customers.
In the final analysis, the only reason that a compeditor would steal from me would be to save time. There will not be anything patentable in this software.
- For most software, paying customers aren't very interested in breaking your license. For instance, as far as I'm aware, Roxen never had any problems with "Roxen Platform"-customers that did things they weren't licensed to.
They bought the licence so that someone else will fix bugs and provide enhansements.
- Source availability can be useful for customers (even if it's a traditional proprietary license, no "free software" stuff), as it makes local patches and bug-fixes possible, for instance, as a part of a support issue.
I use Visual Slick Edit (an excellent product) to edit text. It uses a C like macro language to implement the entire user interface. The source code for just about everything is provided with the package. Looking at that part of the product is just about the last thing that I want to do because of the time it would take.
Cheers, Charles T.
Happy hacking, /Niels
/ Niels Möller (med röd bil)
Previous text:
2003-05-16 22:38: Subject: introduce myself
Hello everyone!
My name is Charles Tilbury and I currently reside in Portland, Oregon, USA. I have been working on developing my own language for several months now, only to discover that Pike is almost exactly what I was trying to make! I only wish I had found out about it earlier.
I need a fast interpreted language with GUI support for Unix, Windows, and Mac/OS. I am planning to make commercial applications in the area of EDA and embedded software developement tools such as JTAG debuggers. I want to use a GUI compatability suite such as wxWindows to allow portability to my chosen platforms.
If I use Pike, I will write the wxWindows/Pike binding and release it under the Pike licensing scheme, but I will probably arrange to encrypt the pike scripts that are part of my applications.
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that:
- The maintainers of Pike are at least not against a project like this.
- That if I decide to write books about Pike and/or the wxWindows binding to
it, that no one has any real objection to it.
I would be very interested in hearing your comments.
Highest Regards, Charles Tilbury
/ Brevbäraren
/ Brevbäraren
/.../ The real issue is "how to map wxWindows C++ classes to Pike classes". I do not really want to write a C wrapper for the classes. <<grin>>
Have you taken a look at the GTK glue (src/post_modules/GTK)? It's autogenerated from spec files.
All one may hope for is to slow down a dedicated hacker. Most people are not hackers and not many people who have sufficient knowledge to hack software are dedicated.
Distributing byte code would be much more of an obstacle than encryption. With encryption, the cracker would only have to locate the code that does the decryption, which would be pretty simple especially since Pike is open source. If he only gets the byte code he would have to reverse engineer all of it. It wouldn't be just a one-time task to crack the encryption; he would have to work for every piece of the code he wants to see.
The downside with the byte code is that it's more work to bring that to a state where it works well for distribution (i.e. is less platform and pike version dependent).
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-18 22:04: Subject: Re: introduce myself
Niels,
On Sun, 2003-05-18 at 02:25, Niels Möller (med röd bil) @ Pike (-) developers forum wrote:
but I will probably arrange to encrypt the pike scripts that are part of my applications.
I'll try to discourage you from doing that (or at least make you clarify what you want to achieve). Which of course doesn't mean that you can't do it if you really want to.
I must say that this is the smallest of the issues that I am facing just now. The real issue is "how to map wxWindows C++ classes to Pike classes". I do not really want to write a C wrapper for the classes. <<grin>>
- Technically, it is not possible to do what you want: Everything needed to run the program must be distributed to the user's computer, which you don't trust. Including any needed decryption keys. It's just a matter of stubbornness to extract the keys.
All one may hope for is to slow down a dedicated hacker. Most people are not hackers and not many people who have sufficient knowledge to hack software are dedicated.
- People interested in running or distributed unlicensed copies of the program (sometimes called "pirates") don't need to decrypt it. And technical tricks like dongles, license servers usually annoy your legitimate users, while being worked around by people that use the program without a license.
I hate dongles.
- As for people (competitors) copying parts of the *source* code for use in their own programs, without any license to do that. Is that a real problem? I've never seen anything like that during the few years I did proprietary software development. It sounds like a very dangerous thing to do. It get's *even* more dangerous if you use a programming environment (like Pike) where the source code is usually distributed to customers.
In the final analysis, the only reason that a compeditor would steal from me would be to save time. There will not be anything patentable in this software.
- For most software, paying customers aren't very interested in breaking your license. For instance, as far as I'm aware, Roxen never had any problems with "Roxen Platform"-customers that did things they weren't licensed to.
They bought the licence so that someone else will fix bugs and provide enhansements.
- Source availability can be useful for customers (even if it's a traditional proprietary license, no "free software" stuff), as it makes local patches and bug-fixes possible, for instance, as a part of a support issue.
I use Visual Slick Edit (an excellent product) to edit text. It uses a C like macro language to implement the entire user interface. The source code for just about everything is provided with the package. Looking at that part of the product is just about the last thing that I want to do because of the time it would take.
Cheers, Charles T.
Happy hacking, /Niels
/ Niels Möller (med röd bil)
Previous text:
2003-05-16 22:38: Subject: introduce myself
Hello everyone!
My name is Charles Tilbury and I currently reside in Portland, Oregon, USA. I have been working on developing my own language for several months now, only to discover that Pike is almost exactly what I was trying to make! I only wish I had found out about it earlier.
I need a fast interpreted language with GUI support for Unix, Windows, and Mac/OS. I am planning to make commercial applications in the area of EDA and embedded software developement tools such as JTAG debuggers. I want to use a GUI compatability suite such as wxWindows to allow portability to my chosen platforms.
If I use Pike, I will write the wxWindows/Pike binding and release it under the Pike licensing scheme, but I will probably arrange to encrypt the pike scripts that are part of my applications.
This is a very large undertaking that I will be working on with no help. I want to the sure before I start that:
- The maintainers of Pike are at least not against a project like this.
- That if I decide to write books about Pike and/or the wxWindows binding to
it, that no one has any real objection to it.
I would be very interested in hearing your comments.
Highest Regards, Charles Tilbury
/ Brevbäraren
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Charles Tilbury -
charles.tilbury＠attbi.com
-
David Hedbor ＠ Pike developers forum -
Karl Pitrich -
Marcus Agehall (Tr�dl�s) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Nilsson (lambda) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Niels M�ller (med r�d bil) ＠ Pike (-) developers forum
-
Olivier Girondel -
Peter Bortas ＠ Pike developers forum
-
Peter Lundqvist (disjunkt) ＠ Pike (-) developers forum
-
Peter M. Lemmen