soft and program: comp.lang.c++ - 18 new messages in 10 topics

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Event dispatcher, hooks and Interceptor pattern for C++?
http://groups.google.com/group/comp.lang.c++/t/a82e5c39e2fe1f12?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 26 2009 5:21 pm
From: Pavel

Lothar Behrens wrote:
> Are there any documents available about the interceptor pattern?
>
> I have a class that registers an event handler to be called on a given
> event. The interceptor pattern then should be used to add restrictions
> or other things to the function.
>
> I could implement that in my dispatcher class (like an event
> dispatcher pattern), but I think there are patterns also usable for
> this issue in C++.
>
> I have cases where I register event handlers per class and others per
> instance (by adding the pointer to the event name). Thus when I have
> an event handler per instance, but a interceptor
> per class I have to strip the pointer from the event name (after
> resolving it from the number) to locate the handler correctly.
>
> Any help out there?
>
> Thanks
>
> Lothar
RTTI in C++ is not sophisticated enough to get you a static function if
you have a typeid or another "runtime id" of the event class.

You could probably construct your own metadata ("Runtime Class") so you
could refer to an instance of "RunTime class" from a virtual method of
your event or from "dispatchEvent" or similar method of your event
dispatcher, based on the result of some virtual method of the event
returning some form of its class id (maybe even typeid).

Alternatively, with somewhat lesser flexibility, you could put your
intercepting logic into the method of the event itself, something along
these lines:

class Event;
class EventHandler {
public:
virtual void handle(Event *)=0;
};

class Event {
public:
void process() {
if (!intercept())
handler_.handle(this);
} // I assume that's what you meant by "adding pointer to the event name"
virtual bool intercept(Event *) = 0;
private:
EventHandler handler_;
};

class ConcreteEvent : public Event {
public:
bool intercept() {
// one algorithm per event class here
// so no need to register
}
};

I am not sure I captured your problem fully; it would help if you posted
some source code to illustrate the issue.

-Pavel

==============================================================================
TOPIC: String not printing data on next line despite \n in the string
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 26 2009 6:30 pm
From: "BGB / cr88192"

"Paavo Helde" <myfirstname@osa.pri.ee> wrote in message
news:Xns9CEDEF04C155Fpaavo256@216.196.109.131...
> "BGB / cr88192" <cr88192@hotmail.com> wrote in
> news:hh5q6c$a8$1@news.albasani.net:
>
>> so, the possibility of a buffer overflow may sometimes be justifiable
>> in the name of performance...
>
> I hope you are joking!
>
> Now, seriously, the unexpected things like the size of input data come
> from
> the outside of the program, by definition. Input/output is typically slow
> enough that a check for the input data size would cost next to nothing. I
> see *no* justification of skipping that! Note that I do not advocate
> dynamic allocation, but just a simple check and error return.
>

there are many cases where strings-based processing may need to be done
purely in memory, and in a performance-critical location.

consider for example, a program drives many parts of its logic via in-memory
command strings.
in such cases, allocating or freeing memory, or sometimes even basic sanity
checking (such as checking that a passed in pointer is not NULL, or that a
string is not too long and does not contain invalid characters, ...), can
risk notably slowing down the app.

for example, I have an x86 interpreter (an interpreter for 32-bit x86
machine code) where, of all things, the main opcode decoder, is based
primarily on strings-based logic code (although it is optimized some via
dynamically-built dispatch-tables and hashing).

another case of strings based logic is in many auto-codegen functions (which
use ASCII command-strings to generate machine code to further drive the app
logic, or build parts of the app's logic-code at runtime).

similarly, this kind of thing may allow many aspects of the apps' logic to
be "human readable" (or, at least as much as a big mass of ASCII characters
can be...), which is much nicer for debugging than having to sort through
binary data (for example, in the form of hexdumps or base64 dumps, ...).

similarly, both my object system and XML DOM code use lots of strings
handling code, and could also risk slowing things down (one may even end up
going so far as to pre-compute hash keys after noting that a notable amount
of time was going into simply recalculating the hash value during lookups).

granted, in the OP's case, performance is probably not all that important...

>> (not wanting to make debate here, but there are reasons to choose one
>> or another in different contexts, many not particularly relevant to
>> the language as seen/written by humans, and many not related to the
>> "majority" of projects).
>
> I cannot see any reason to knowingly leave a potential UB bug in the
> program. God knows there are many of them already left unknowingly, no
> reason to add one!
>

these can be "boundary conditions", and are normally weeded out elsewhere.

but, alas, there may be a lot of consideration as to whether it is better to
leave a possible bug, or fix it so that it doesn't risk crashing or posing a
possible security hole.

one can then use the debugger and test cases to determine how generally
reliable the code is (AKA: how many bits of bad data can escape through the
proper "safety nets", as well as how well everythings actually works), and
profilers to determine where optimization is needed.

> Paavo

==============================================================================
TOPIC: C++ jobs down another 40%
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Dec 26 2009 6:40 pm
From: tanix@mongo.net (tanix)

In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192" <cr88192@hotmail.com> wrote:
>
>"tanix" <tanix@mongo.net> wrote in message
>news:hh4vpq$304$1@news.eternal-september.org...
>> In article <hh4fo1$7p6$1@news.albasani.net>, "BGB / cr88192"
>> <cr88192@hotmail.com> wrote:
>>>
>>>"tanix" <tanix@mongo.net> wrote in message
>>>news:hh3nuq$14q$2@news.eternal-september.org...
>>>> In article <hh3ne4$7k2$1@news.albasani.net>, "BGB / cr88192"
>>>> <cr88192@hotmail.com> wrote:
>>>>>
>>>>>"Chris M. Thomasson" <no@spam.invalid> wrote in message
>>>>>news:xR9Zm.3013$8e4.2445@newsfe03.iad...
>>>>>> "tanix" <tanix@mongo.net> wrote in message
>>>>>> news:hh31vk$82i$1@news.eternal-september.org...
>>>>>>> In article
>>>>>>> <66e7b0f7-4c71-4db4-a9f1-3f9d7e4dc5a5@a32g2000yqm.googlegroups.com>,
>>>>>>> James
>>>>>>> Kanze <james.kanze@gmail.com> wrote:
>>>>>>>>On Dec 23, 11:02 pm, red floyd <redfl...@gmail.com> wrote:
>>>>>>>>> On Dec 23, 12:50 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>>>>>>>>
>>>>>>>>> > The number of job adverts in the UK citing C++ has fallen
>>>>>>>>> > 40% for the second year in a row:
>>>>>>>>
>>>>>>>>> Hey, Jon! Wha'ts the market for F# jobs like?
>>>>>> [...]
>>>>>>>
>>>>>>> Well, I just looked at it on Wikipedia:
>>>>>>> http://en.wikipedia.org/wiki/F_Sharp_%28programming_language%29
>>>>>>>
>>>>>>> Looks like another bluff to me. All sorts of bells and whistles.
>>>>>>> For me, personally, it is a no go, and primarlily because it is
>>>>>>> based on .net framework.
>>>>>>
>>>>>> FWIW, here is a fairly portable C# and CLR implementation:
>>>>>>
>>>>>> http://www.mono-project.com
>>>>>>
>>>>>
>>>>>yep, in my case, I acknowledge that mono exists.
>>>>>looking deeper into the project though, I am personally a little less
>>>>>compelled:
>>>>>it is, IMO, poorly architected and built on terrible code (and terrible
>>>>>coding practices).
>>>>
>>>> Uggh. That one is going to wait then.
>>>>
>>>
>>>well, I guess it is probably not so bad if:
>>>one only really expects it to work on Linux, and uses MS's .NET on
>>>Windows;
>>>makes sure to pretend (sort of) that they are coding on Windows, and stays
>>>clear of Mono's extensions (mostly GTK bindings, glue into a bunch of
>>>GNome
>>>related stuff, ...).
>>>
>>>personally, I would have assumed making a new GUI API, which was generally
>>>free of being tied to a particular OS-level GUI. I don't like the idea of
>>>coding against a GTK wrapper, as personally I don't want to be tied to
>>>having to use GTK.
>>
>> Sounds horrible.
>>
>>>but, this is not the end of it, as it is worth noting that Mono itself is
>>>tied to GTK at a very fundamental level (IOW, a lot of the core VM code is
>>>built on GTK's API functions, on GLib, ...).
>>
>> GUI IS one of the biggest problems.
>> I had a chance to look at some of those toolkits in passing.
>> Horrible stuff.
>>
>
>yep...
>
>and one can also wonder why parts of the core VM (JIT, PE/COFF machinery,
>....) need to be dependent on GTK and GLib (using GObject, ...).

Well, at least I do not have to worry about it.
Probably for historical reasons. After all GTK is one of the oldest
toolkits around.

>granted, I guess there is a partial solution, which is to use basically a
>stripped-down dummy version of GTK for building the VM, but I dislike this
>having been needed in the first place.

I am not sure how easy it would be to do it with something else.
After all, almost anything I saw in terms of graphics on Linux/Unix
looked to me like a nightmare.

What a pitty.
I do not claim I am aware of all the "progress" that has been made,
but I think it is one of the weakest points of Linux/Unix.

Furthermore, from what I recall, it is not even a single layer
of abstraction. There is this dinasaur X11 stuff and on the top of it
some GTK and on the top of that is Gnome if you are talking the O/S
level user interface. But I am exactly a reference point on this.
I did try to look at some graphics related stuff, but every time
I had goose bumps just trying to figure out what is what and who is
who.

>> I think there needs to be some portable GUI subsystem so you don't have
>> to worry about one toolkit on one platform and totally different way
>> of doing it on another.

>agreed...

>sadly, the best option in Mono's case is "Windows Forms", if anything
>because it directs to GDI on Windows and GTK on Mono.

Windows forms immediately triggers the visual basic syndrome in me.
:--}

But what I do have to agree that it is pretty easy to graphically
design some of your GUI stuff with it. But that is about all the
good news about it.

>> Something like it is in Java for example.
>>
>> Otherwise, they keep reinventing the wheel and none of it you can
>> rely upon as a single version of your code.
>>
>> Unfortunately, you need some equivalent of JVM to do it to shield
>> you from the O/S particularities.

>one can get "halfway there" via clean coding practices.

Well, may be. But when you start from scratch, the curve is too steep
in terms of time and effort for you to get something realistic done.

It is much easier to rely on things like swing or even awt.

>> But I think we are at the point where things like JVM or MVM
>> or that sucky .net are essentially what virtual machines are.

>> Processing power and memory limitations are no longer there.

>but, it is not good to waste them either...
>many of us do write code where performance matters, and where seemingly very
>little issues in the right spots can eat lots of clock cycles or memory...

Yep. No questions about it.
But at least if there was some lanugage facilities you could rely upon,
the stuff under the hood could be optimized as it forever happens.

I am not sure how much of a performace factor the GUI code would
be dependent on. Some key listeners, some event listeners, the async
processing and things like that.

I have pretty large dialogs I would say, probably with at least 50 components,
and in some cases 3 times as much. Never ever felt any kind of performance
issues with it. Sure, if you do real time graphics or 3D app, that could
be a totally different story. But I have no clue in those areas.

As long as it is not a real time stuff, I doubt GUI is subject to
performance issues.

>> It is understood that at a time of P-Machine (Pascal), which was meant
>> to significantly improve the performance of Pascal, it was unrealistic
>> to expect that the idea will be accepted, and it was not.
>>
>> But now things are different.
>>
>> Basically, the portability, a single way of saying something,
>> without worrying about the O/S, environment or anything for that
>> matter is what is needed more than anything else.

>I disagree in the strict sense.
>if the code can be rebuilt easily enough for the various target OS's, this
>is often "good enough".

Fine with me. I am willing to take a source level portability.
For as long as I don't have to give an arm and a leg to sharks like
Microsoft or Google.

>virtualization can help, but usually it is far from free either.

>for example, neither JVM nor .NET will allow one to use the same code for
>both a hosted and native build, and IMO this aspect is important as well...

Well, I am not even dreaming of that level of portability.
At the moment, we are just totally empty handed.
And if it takes several years for those "committies" to come up to some
kind of agreement, I'd rather take at least some of it, if it can be done
"real soon now". As long as they are not going to change it every day.

>granted, if I compile a bunch of Java to a native EXE or DLL, it can't
>really be expected to run on, say, Linux, but this much is not the issue.

Yep. Source level compatibility AND the ability to compile it to
a natural way things are executed on a given platform, is fine with me.
Actually, that was my argument with Java guys a while back.

I said: when I run a windows app, I expect it to be an .exe file
that I can simply click upon to run the app. Because THAT is the way
every runs under windows. Everybody knows it, and everybody is used
to it.

I do not even want to know that there are some funky portable .class
files underneeth, and those are the actual things that run.

And this is a fundamental conflict with the very concept of ?VM.

Because if you simply want to have an exe, then, by definition,
you need to compiler your ?VM either into a single executable,
or executable that simply loads some dll.

And that kinda breaks the whole idea behind the JVM at least
since class files are your final "executables".

JVM executes a pseudo code, not a native mode code.

> it
>would be better if one could compile it in both cases, rather than creating
>yet another barrier:

Totally agreed. I want to see it compile into a single native mode
app that may or may not use the dlls under windows.

But then I am not sure how would you go about with the very
concept of ?VM.

>Java code is, always, run in the VM;
>native code is C and JNI.

>there are at least several JVM's which ended up allowing running the C code
>in a VM as well (just x86 based rather than JBC), but still using JNI to
>interface them.

I am sure there are ways to solve these kinds of issues.
Exept everybody is busy erecting the castles on a see shore
from what I see.

Again, I am very displeased with the direction of language
development in general, no matter where you look.

I think is is a totally dead end approach.

They are not even looking at the most critical issues to a developer,
and "could care less" about what is happening in the world in terms
of it being more and more dependent on the information processing
aspect, such as web.

I doubt what people need is some "revolutionary" syntax.
Have not seen ANYTHING that excites me in F#, even though it looks
nice on paper. I have not seen things like GUI, threads or GC
even mentioned.

Why do you think PHP, Python, Ruby, Javascript, SQL and even HTTP
are so appealing.

Vast majority of web based apps are developed with PHP from what
I see. Most of CMS systems, bulletin boards and you name it use PHP,
even though Python and Ruby have much higher performance.

Just look at the very central idea of PHP that you can mix
your html code with php, however crazy it may sound, and it does
sound crazy to me. But it gives people so much power and flexibility,
that any kid cad deveop something working within days, even though
they might have never heard such things as synchronicity,
threading, acync processing events and things like that.

And THAT is what is happening in the world, and I bet you,
it is going to be happening more and more.

People do not even know about the portability issues.
Because they simply do not exist.

They could care less if you run JVM or anything for that matter.

They don't care how "pure" is your syntax and notation
from the standpoint of some "head".

They do not know what means static binding or dynamic binding
necessarily.

And yet, there is a tremendous amount of work being done
and it does what they want.

Why not look at it as an opportunity?
Especially if you have the underlying principles that allow
you to run orders of magnitude more efficiently?

Why not look at THESE things instead of sitting in an ivory tower
and keep inventing some new mental perversion that will make
people shiver when they look at it?

>> I personally think F# is a flop, no matter how many people join
>> the camp. It is a convoluted, over complicated pile of concoctions
>> that try to give you all sorts of bells and whistes to the point
>> that they even try to address the database issues and do some
>> hacks of Javascript level where functions may include other functions
>> as parameters. It is a mix of Lisp and Javascript. Essentially
>> the same idea of dynamically built code. Except complexities
>> and the very concepts are as flaky as it get from what I see.
>>
>> Building a dynamic code that can go as far as dynamically construct
>> some other code is not exactly a new idea, going back to Forth,
>> Lisp, etc.
>>
>> But the very concept is flawed. The code becomes utterly unintuitive.
>> You can not even comprehend what comes out of it at the end.
>> I talked to Javascript guys and they said once you hit a certain
>> problem related to this kind of stuff, good luck. Because it is
>> going to be a hell for you to fix it and you may have to spend
>> months on it. I'd say I agree after looking at Javascript.

>yeah.
>dynamic languages tend to have a certain limit to their scalability.

For one thing. Except you need at specific app.
If it is a server end, yes, there is a need for scalability
and performance, and I think Java solved it quite nicely.
Not saying it is the "ultimate" solution. Because none exists in
principle.

>some of their abilities are really nice and powerful at the small scale, but
>the bigger a project gets, the harder it gets to manage.

>many static languages tend to scale much better.

Sure they do. That is the whole point of them.
And that is why I'd like to see a STATICALLY scoped (typed :--})
languages to at least consider the modern world.
Because they don't even bother about anything else, but their own
lil sandbox in the scheme of things.

>my intuition here is that probably C likely scales fairly well (if practices
>are good), with C++ and Java likely comming close (again depending on
>practices, Java will likely allow scaling easier at the "medium" scale).

Except it is used on the largest scale in banking, finance,
wall street, governments, etc.

>JavaScript is not likely to scale well.

Well, it does not need to. It is a client end gizmo.

>guestimate:
>C (with poor practices), likely to turn into an ugly mess at around 30-50
>kloc;
>C++ (with similarly poor practices), maybe around 50-75 kloc;
>Java (with 'generic' practices), likely at around 200-400 kloc.
>
>in C and C++, the user is likely to end up stumbling around with globals and
>memory objects...
>
>in C++, the limit is likely to be a slight bit higher, due mostly to the
>programmer trying to naively use namespaces, classes, and RAII as "magic
>pendants".

I like this one:

"only real danger is that we simply forget to release the resource,
which, while it does happen, is something that should be quickly caught
in any code-review."

What a joke!

>this would work for a little while, but ultimately these can't
>save poor practices (for example, a global in a namespace is still a global,
>....).

>by adapting many coding policies, the situation is reversed, very possibly:
>C (good practices), ~ 1 Mloc;
>C++, ~800 kloc;
>Java, ~ 500-600 kloc (?...).

>reasoning:
>in C, one is likely to have learned early on that fairly rigid coding
>practices are needed to help code scale, and if followed make the natural
>large-scale structure somewhat different from its smaller-scale form.

>C++ is similar, but I suspect it is likely that there will be some
>"aliasing" related to misusing some OO features in ways which create
>"tangles" (very likely, the same features which tend to help at the smaller
>scale).

>actually, from my experience, a sufficiently large C or C++ project is
>likely to start notably resembling an existing OS, such as Linux or Windows
>(or at least, this was my experience...).

>Java is not likely to help, since the language itself has a fairly
>restrictive design, and it would be awkward to use a large-scale
>architecture in conflict with the languages' built-in architecture. I could
>be wrong though, not having had much significant experience in the language.

>JavaScript is not likely to scale well much above maybe 10-25 kloc, and
>attempting to adapt modular practices would make the language likely
>somewhat unappealing.

>the advantage if offers then is that, given it is likely to be used for
>scripting rather than for infrastructure, code is likely to be small and
>divided up into disjoint islands, which would help keep issues more-or-less
>contained (the number of such islands should not be a significant factor
>beyond the level of code one has to deal with).

>> A while back, I had the same idea, except it was for database
>> applications. I asked a question: what prevents you from writing
>> a database stored program where you use the rows to store your
>> high level instructions? Well, nothing really. I implemented in
>> and it worked just fine. But then it withered away. Basically,
>> I stopped working with database.
>>
>> Now they have it all over the place.
>>
>> But there are plenty of disadvantages of such an approach.
>> It lacks the necessary structure. Yes, it is as portable as it
>> gets, but you don't have that "super-language" syntax. It is
>> all disassociated set of instructions, no matter how high level
>> and how powerful they are. It lacks the properties of high
>> level languages.
>>
>> So, my opinion on this is that people think "it would be nice"
>> to add the ability to construct the programs. But they seem to
>> fail to comprehend that your very language becomes a nightmare
>> in the modern world.

>ok.

>> Again, people do not have neither time, nor interest to waste
>> hours of their time to either read some complicated goubledy
>> gook code, that takes hours just to understand what it does
>> essentially because of the most horrible, utterly unintuitive
>> language syntax constructs, and I specifically mean generics.
>>
>> When and why do you need generics and what does it buy you?
>> Well, I can find only one place in my code, and that is a relatively
>> large piece of code, where "generics is a must". Lucky me,
>> I can not even use generics because it is not supported in
>> my development environment, thanx to these wars between
>> Microsoft and Sun.

>newer Java does support generics, FWIW.

I know. Except VS 2005 is the last version of IDE that supports
Java syntax. Beyond that, there is no concept of anything even
remotely related to Java. Thanx to these Sun vs. Microsoft wars.

>> So, I had to implement it using the "copy/paste antipattern" and
>> I have about 3 copies of exactly the same logic, dealing with
>> 3 types or argument.

>> Do I regret it? - Nope. Not to the least.
>> Did I EVER have ANy problems with it? - Not that I know of.
>> I don't even notice this code. Works like a champ.
>> And each of those methods take about 10 lines of code.
>> Why would I bother to write some ugly code using generics?
>> I would not even THINK about such a think. UTTERLY usesless.

>> How many places in your code do you have that do very similar
>> things? Well, I bet ALL over the place. Would you need to
>> replace it with generics? Well, try.
>>
>> One professor from France, a while back said:
>> Writing programs automatically is just a myth that will never
>> happen. Because each program is unique and has millions of
>> nasty little things that distinguish them from something
>> similar.
>>
>> Otherwise, we would not have a software industry by now.
>> It would be all generated by the software robots.
>>
>> And with all the "developments", interfaces, OO approach,
>> it is still a myth, just the same.
>>
>> I do not think THIS is the priority of development and THIS
>> is what is going to imporve the sofware design.
>>
>> And I do not think that introductions of more and more
>> complexities into syntax and notation is going to solve
>> ANYTHING. It is just going to create more and more headaches
>> as it becomes more and more unintuitive.
>>
>> Language designers seem to be totally oblivious of the fact
>> that their language is not exactly what is going on in the
>> programmers or designer's mind. They need some specific
>> JOB to be done. Some specific CONCEPT to be implemented,
>> some specific ARCHITECTURE that will do such and such.
>>
>> They could care LESS if your obscession with languages means
>> something to you as language designer. I do not recall many
>> cases, if any, where I thought: oh crap, I can not do this
>> and that because my language SYNTAX is screwed up, or my
>> espressive power is not enough.
>>
>> But I do recall TONS of cases where I had to waste almost
>> half an hour of my time looking at some utterly ugly code,
>> written by some idiot with complex of inferiority, that
>> probably wasted DAYS of his time to write some generics
>> goubledy gook code that was not even needed to begin with.
>>
>> I could do exact same thing with funken C code, not even C++.
>> And the hell would sooner get frozen before they can prove
>> ANY advantage of that "purist" code and all those compile
>> time "benefits" they get out of it.
>>
>> But no. These suckers need to show the whole world how "smart"
>> they are. You see, they can OUTSMART you!
>> :--}
>>
>> What a bunch of sickos, utterly brainless idiots, driven by
>> the complex of inferiority, forever trying to prove everybody
>> how "smart" they are. Why do you need to even bother with such
>> foolish things? I simply can not find a bettter term for it.

>....

>>>I at first put some effort into trying to get it to build from sources on
>>>Windows, but was having far too many difficulties, and personally found
>>>the
>>>code a bit nasty, so quickly enough gave up.

>> Hey. Thanx for your feedback. That is exactly the kind of thing
>> I need to hear. The last thing in the world I am interested in
>> wasting weeks, if not months of my time just to eventually realize
>> I was screwed again by some fools, selling me pussy in the sky with
>> diamonds.

>>>I later started looking into writing my own .NET implementation, but this
>>>petered out, as my frameworks' architecture started taking shape on its
>>>own,
>>>but is not a whole lot like the .NET VM.

>>>actually, my project is a lot more of a chimera (some parts influenced by
>>>the JVM, others by .NET, others by GCC, others by LLVM, ...).

>> Well, would be interesting to see what kind of thing you came up with.
>> You can write an article on it. Don't worry about that "off topic" crap.
>> We'll fight if we have to.

>well, for the most part, it is not particularly "compelling".

So what?
You did spend some time thinking about these things.
Don't you think that the results of it is worth some value to others?
And even if you are "wrong" and they jump on you in bulk,
what is "wrong" with that? Who knows, may be some new insights
may come up out of it, for you and for them?

I do not think it is such a good idea to simply let your work
go to waste because you are aftaid of being condemend.
Screw that stuff. One of the most pitiful things.

I think if you have done some work, it is imperative you talk about it.
It may generate new ideas for others and for you, just be the shear
fact that you EXPRESS it. Take it from subconscious level to conscious.

Do not underestimate the significance of it.

>it has nearly all of the parts of a traditional compiler:
>preprocessor, frontend, IL, codegen, assembler, linker.

>the input language is C, the IL is a little funky (and obscure Forth or
>PostScript like language, sent between stages in a textual form), the ASM is
>essentially a variant of NASM / YASM style syntax;
>the assembler produces COFF, and the linker accepts COFF.

>it "may" use a custom name-mangling scheme, which is largely a hybrid of
>JVM/JNI naming, and IA-64. basically, it combines a lot of the notation from
>IA-64 with the general syntax of JVM signatures, and then converts it to a
>linker symbol with a convention based on that used in JNI (although, it has
>special-cases for several additional characters, as well as a shorter escape
>for chars in the 1-255 range).

>this particular type-signature scheme is used by many internal components.

Look, I can host your project and ANY documentation you have.
We'll make a separate "site" for it that contains the interesting
projects in the area of language or system development.
You'll have your own top level link that will be shown in the
top level index.

That is what I can do.

This should not go to waste in my opinion.

>> however, I think its only real advantage is that I personally feel the
>> role
>>>of the VM is different, and so there are many "philosophical" differences.

>> Like what?

>both the JVM and .NET want to remake the world in their own image,

YES.

> and set up "the one true VM to rule them all".

Well, except in case of microsoft, you'd have to say
"to rule them all as long as you are dealing with OUR stuff".

That makes a difference.

>I disagree with this strategy.

>a VM is, IMO, "a framework" not "the framework".
>hence, in this sense, I am a little more closely aligned with Python or Lua.
>(although, I personally don't have so many happy feelings towards Python
>either).

The only thing that prevented me from geting into Python,
even when I needed to, was abscence of braces.
The very idea of using white space as indentation level is bizzare.
Just this single thing was enough to stop even bothering with it,
and when I read his arguments on WHY did he do it, it was just
a bad joke to me. To try to fit as much code on your scren as you
want by simply removing the most stable code block delimiters,
is simply insance.

On the top of it, when I read some of original documentation,
it seems like the guy has difficulties with comprehension skills,
jumping right into middle of such nasty things like regular
expressions and not being able to explain every step of the way.
Some syntax issues with regex are totally unintuitive.

Some other stuff like installation subsystem borthers on insanity
to me. When I looked at documentation, it was just like reading
a bible sized book with ALL sorts of blabber, just to copy some
stinky files around and set up some relatively simple things.

As a result, full stop on Python. Regardless how many people
say it the the solution to mankind's problems. Python is hack.
I like "real" languages developed by people, who has seen it
all in and out, and not by some smart "wizards".

>> You see, what I am beginning to sense more and more that the solution
>> to language and portability issues is that very VM as a concept.
>>
>> And I think Java is a perfect example of it.
>> Because it demonstrated in practical terms that the whole language
>> becomes much more powerful (in my opinion) and MUCH more portable
>> and all sorts of portability related issues could be resolved,
>> and GUI, threads and garbage collections could be wired right into it.
>>
>> So, once you have a VM that handles all those nasty details,
>> you are shielded from ALL sorts of problems and issues.
>> Yes, that VM probably have to have some web related functionality
>> wired right into it. Plenty of people complain about very primitive,
>> low level support for web apps in Java, and I trust what they say
>> and I can see some of it, and I think the language and VM
>> designers need to pay MUCH closer attention to what they ask for,
>> instead of inventing some ugly even even more complicated stuff
>> with language syntax and semantics, that turns out to be some
>> of the most useless thing at the end just because no one really
>> needs it in forseable future. It all just adds to conceptual fat
>> at the end.

>yep.

>well, there are merits to VMs, and there are costs...

I'll take the merits and accept the costs.
What other options do I have?

>I don't personally believe in aboloshing the JVM, only that I think the way
>the overall architecture, and the way Sun is managing some things, are not
>quite so ideal.

May be. But I'd be REALLY careful making these kinds of statements.
But if you have a better idea, why not?

>granted, not everyone has the same needs or ideals, and what the JVM
>addresses are a slightly different set of ideals than those I am trying to
>address.

And those are?

>granted, Apache Harmony and GCJ are both pseudo-JVM's, both of which adapt
>both Java and much of the JVM architecture, but each varies in some notable
>and fundamental ways:

>Harmony seems better adapted as a script VM (for example, for the Apache
>web-server);
>GCJ can compile Java code to native machine code and link fairly directly
>with C++.

Oh, now I remember about that GCJ thing. I think I looked at it
a while back, just in passing. At that time, I did not believe
they are really selling something real and I did not have any first
hand experience with it. So I had to abandon it.

Is it something worth looking at in your opinion?

>what the JVM offers is OS abstraction via a virtualized architecture.
>granted.

>some people don't need this though, and instead want a good scripting VM
>under the control of a host app, which is a role thus far best filled by
>Python and Lua.

Well, then have two VMs. I could care less for as long as I know
when I do this and that, I have to type a different command line,
or something like that.

You keep mentioning Lua. Have no clue about that one.

>another need is for good performance and powerful app extensions, which is
>better filled by C (high level script languages are good for scripting an
>app, but not so good for extending it).

>I have some hope of being able to have JVM features available as well, but
>my motivation has been lacking (the JVM facilities I have in place are not,
>what I would call, "usably complete").

>many notable VM features (such as exceptions) don't work, and I don't have a
>class library (there was some attempt to port over GNU classpath, but this
>petered out some and I have my doubts about using such a massive GPL'ed
>component).

:--}

Yep, massive seems to the point.

Well, not sure what you have been cooking there and why did you
have to design your whole world to do things, but I guess you had
your own reasons to do it this way.

>>>personally, I rather dislike monolithic architectures. and so, much of the
>>>architecture is based around loosely coupled "modules" or "components",
>>>and
>>>some effort is put into making these compoents too specific, even to each
>>>other.

>> Sure, why not?

>>>so, my beliefs here are that:
>>>the world does not revolve around the VM, the VM framework should "assist"
>>>the app, not "dominate" it;

>> Well, it does not have to DOMINATE it.
>> But it CAN assist it, so you don't have to worry inventing another
>> language to use some of those things, so necessary from the standpoint
>> of portability, such as GUI, filesystem layer, threads, GC and other
>> basic and universal mechanisms, needed by just about any app out there.

>> I don't think you can even argue the case of VM being "evil"
>> even on an embedded system, even though that is a stretch.

>well, I am one of the rare VM developers who is probably not promoting yet
>another new bytecode or programming language...

Well, I am not exactly an expert in this area.
Never quite grasped the idea behind the bytecode.
If someone tells it to me in few words, find, I'll look at it.

What is the primary motivation behind the bytecode?

>for some things, I am using JBC, and for other things I have adopted 32-bit
>x86 as a "bytecode" (good and bad points exist here...).

You seem to be gettin to deep into those nasty details.
Like designing your own world from the O/S level and up.
I wonder WHY do you need to poke THAT deep into this stuff.
Is there are philosphical reason behind it?

>currently C and Java are the main "script" languages in use,

SCRIPT language?
:--}

I like that one!

> however, I
>can't currently compile Java on my own (I have ended up having to resort to
>GCJ to do the first-half of this process).

>I did try to plug Java support into my C frontend, but this turns into a big
>mess, as my compiler backend can't really deal with Java's constructs
>(trying to shove C and Java through the same compiler backend is not nearly
>so easy as it would seem).

Oh, maaan! You must have some royal amount of free time
to dig THAT deep into it.

>I may instead switch to an alternative strategy, and maybe get around to
>writing a Java compiler which produces JBC / "class" files,

Jeez!
:--}

I feel sorry for you. What a task!

> and then make
>use of my JBC interpreter, or a translator, for plugging this into the rest
>of the VM.

Are you trying to reinvent the software busines?
:--}

Your own VM, your own language, your own interpreter, your own translator.

Maaaan!

>my JBC -> C translator had been mostly so that I could compile Java into
>native DLL's via MSVC (mostly to avoid having to send it all through the
>classloader, getting better performance, ...).

EXACTLY what I'd like to see.

>however, issues popped up which stalled this effort.

>the result is that Java has not made "significant" inroads into my codebase,
>and so C remains as the primary VM language (as well as the implementation
>language).

>I am still left with doubts though, and if it goes anywhere may end up
>either using Apache's class library (instead of GNU ClassPath), or maybe
>writing my own mini class library ("java.lang" and maybe a few other areas,
>but leaving out most of the rest).

Well, I definetely think you should organize your material
and make a good site to publish your findings.
You never know, you might find some other people, crazy enough
to join your club.

>similarly, finding a "better" option than JNI could help (VM-based scripts
>using JNI just seems horribly tacky...).

>>>it should be possible to use which parts are needed, and discard the rest
>>>(or supply alterantive implementations, if this is needed);

>> I totally agree. Dynamic system wiring is probably more beneficial
>> than most of bells and whistles I see.

>yep.

>this is all more a matter of coding practices and architecture though,
>rather than any particular features.

>often, native OS-level API's do this far better than nearly any VM I am
>aware of.

Fine. So make a thin interface layer above it.
But make it platform independent.

What I, personally, want is a SINGLE way of writing something.

I want platform independence in STATICALLY scoped (typed :--})
languages. No matter what anybody says, I am still very hesitant
to jump into these dynamic languages. I did look at some of it,
but my heart is somehow not at rest with it. It says: nope,
it is a trap. Don't go there.

Most dynamic languages are way too limited.
I like to see ALL the bells and whistles of static approach,
such as threading, async handling, event structure, performance,
predictability of outcome, and things like that.

> this is mostly since most VM's try to package everything into "one
>size fits all" objects, and may end up with a big pile of different classes
>for every possible use case.

Yep. I do not like that aspect of it.
If you could construct that VM on the fly, depending on what exactly
my app requires, that would probably make the whole thing leaner.
Not sure how realistic the whole excersize is though.

>granted, generic facilities are often not as "nice" as in the "one size fits
>all" strategy (often, the more control that is given, the more internal
>patchwork that is visible), and having to bring up subsystems by getting and
>setting lots of pointers isn't very nice, but it does have some merits.

I could care less about what kind of magic you need to do
while that thing is constructed at run time.
As long as it buys me something at the end.

>>>the architecture should remain relatively open, as not to overly limit
>>>possible use cases (consider if the VM is composed of lego blocks which
>>>can
>>>be put together in different ways under the discretion of the frontend
>>>app);

>> I'd LOVE to see THAT kind of thing.

>well, it is an ideal at least.
>the tangled bits and need to mess around with crap sometimes clouds the
>vision.

Just don't spread yourself too thin.
I am not sure you have resources to handle so many different aspects.

>I guess it can be compared to trying to write an app making use of DirectX.
>luckily, much of this internal plumbing work is hidden in the details, but
>at the cost that this (doing initialization automatically), itself, creates
>more internal dependencies and issues.

Well, what do you expect if you are trying to reinvent the world?
:--}

>>>the VM should also play well with pre-existing technologies (I have tried
>>>to
>>>base many of the components after fairly "standard" pieces, and although
>>>imperfect at times, it is possible to use "off the shelf" apps for many
>>>purposes, both to provide input or accept output);
>>>....
>>
>>>so, I am at odds with both .NET and the JVM on philosophical grounds;
>>
>> I don't want to even HEAR about .net or asp.
>> To me, that equates with profound evil, whose only purpose is
>> to dominate the world. The same thing as NWO, only in sw business.
>>
>> That stuff is out the window for me, and for good.
>> From my end, it is RADICAL non acceptance of the whole underlying
>> philosophy of it, which is nothing more than maximization of the
>> rate of sucking of the blood of many by the few.
>>
>> It is total NON portability.
>> It is a police state equivalent of the "matrix", the sowtware industry
>> version of it.
>>
>> It is a dead end that will NEVER, under ANY circumstances,
>> will either solve any problems we are facing right now,
>> or make things EASIER in order to make some genuine progress.
>>
>> It is nothing more than a giant speder web, whose square purpose
>> is to catch as many flies and get them entangled in a deadly dance.
>>
>> It is UTTER NON cooperation. It is an idea of total control of destiny
>> of human kind that eventually translates into a two class society,
>> the "elite" and "slaves", and this is not just some "conspiracy
>> theory". This IS the reality of what is going on.
>>
>> Those anti-globalists are not just some bunch of fools.
>> I just learned recently that their leader happens to be a former
>> supreme court justice. Someone who knows this thing so good, that
>> many sculls are going to get cracked to even comprehend what he knows.
>>
>> Must be a person of total honesty to take SUCH a grand risk.
>> He can be killed ANY moment and he knows that all too well.
>>
>> THESE are the kinds of people that need to be involved in politics,
>> if we are to get any benefit for ALL, and not just fattest parasites,
>> sucking every drop of blood they can find from the body of
>> mankind.

>ok.

>>>and, I disagree with LLVM on architectural grounds (granted, I have a mess
>>>here, but personally I just don't really like LLVM's architecture);

>> Sorry. Do not know what LLVM is.

>LLVM is another VM, but which mostly sets itself up as a generic compiler
>lower-end.

>my main complaint is that the design is very centralized, and also that the
>whole thing is written in C++ and in a style I am not particularly fond of.

>may seem odd, but I believe the lower-end compiler machinery should be,
>hopefully, decentralized and C-friendly (C++ can be used, but one should not
>expect any code which externally interfaces with it to do so by instancing
>or extending classes, ...).

>I am also not as fond of the single-class-per-file or manually including
>"teh crapload" of class-specific headers, mostly because it means having to
>open and dig through far too many files to really follow the code.

Well, Microsoft did not have that limitation, and I totally agree
with that one. But it seems to be some kind of necessity overall.

But what a royal pain it is. My main class source file is > 250k.
Not that it is such a big deal with modern IDEs. But still, I'd
prefer to see it split into smaller, logically related sections.

>>>....

>>>however, I have tried to minimize creating "novel" parts when possible.
>>>
>>>sadly, some level of "novelty" and "internal dependencies" are inevitable
>>>it
>>>seems...

>> Sure. There is no way around it. That's the whole trip of it at the end.

>>>thus far, much of the VM revolves around "good old C", both as the
>>>language
>>>of implementation, and as the language of scripting. I have attempted to
>>>move beyond C (Java and C# looked like good languages to try to add, and
>>>JavaScript and Scheme also have some interest).

>> C# - full stop.
>> Red siren: WARNING: You are entering the domain of The Head,
>> Microsoft, the Evil Most Profound.

>> Unless C# is accepted by everybody and unless it is not a subject
>> of copyrights and pattents, I would not touch it with a 6 foot poll.

>> There is simply no need for it to begin with.

>> C# does not solve anything so radical that is is worth even
>> bothering with, regardless of how many language "experts" say
>> it is salvation for mankind.

>there is ECMA-334 and 335, which essentially mean that, as far as these
>parts go, there is some level of openness. one can then implement which
>parts are defined in these standards, and ignore most of the rest, and
>technically MS is under their own legal obligations not to do anything about
>it.

I just do not trust those guys ANY way you cut it.
From what I've seen so far, these are just different kinds of traps,
but you do eventually get trapped in that gook. And it is amazing,
they did not realize how much they are hated by just about anyone
for setting up all these traps and being totally closed, ignoring
the rest of the world, like they are the only ones that have a final
say on what is what.

>granted, you wont get the whole ".NET framework" this way, but one can get
>C# and MSIL, which have a few merits.

Well, I do not mind C# as such. I am looking at some things in passing,
and yes, it does make SOME sense. I just fail to see what it boils down
to at the end and what specifically does it buy me.

I think people are too obscessed with compile time issues.
For example, in Java generics, there is this type erasure thing,
which means you loose your type during the run time.
Well, I do not like the mechanisms like these in principle.

>the problem, however, is that both are fairly complicated in their full form
>(much more so than the JVM equivalents), and so would take a far higher
>resource involvement to really implement effectively.

I just do not see what does it buy me at the end.

If your program is "incorrect", you can not be saved by compilers.
Those are just small things that won't make your program "better".
Because you prolly have holes in your architecture and design.

People still write plenty of code in straigt C.
For some strange reason, it is all over the place.
And the more stable, more performing code, the more you get to the
kernel level, the closer you tend to move toward C.

>>>however, it is all a bit of a "trudging through mud" experience,

>> And forever so.

>>> and C
>>>remains as the only really "usably complete" language in the mix

>> Indeed. It is the ONLY true "revolution" in the software industry,
>> that contributed more to it than all the other stuff combined.

>yep.

>>>(my C
>>>compiler contains a few holes and failings, but for the most part it is
>>>adequate).

>> You mean you have your own C compiler? :--}
>> That made my day!

>yep.

Wow!
I am impressed.

>it is mostly used for scripting.
>for most other things though, I am using good old static C compilers (GCC
>and MSVC), which do most of the "heavy lifting" as it were.

>my compiler is binary compatible with the static compilers (so I don't need
>a FFI for C-based scripts).

>>>but, ideally, an app will "use" a framework, rather than be "built on top
>>>of" it,

>> What do you mean by that?

>an app which uses something may continue to function without the object in
>question, or may supply a substitute.

Cool. You are pretty inventive I'd say.
:--}

>an app which is "built on top of" something, can't be reasonably expected to
>function without it.

>for example, an app may use a GUI toolkit, or several of them, and then some
>way exists in which to "choose" which one to use (via build options, or even
>at runtime), or the app could provide a fallback (no GUI is available, so it
>falls back to a custom and more-simplistic interface, such as a
>command-line, or simple custom-drawn widgets).

You are really something else, I tellya.
:--}

>an app "built on top of" a GUI toolkit can't easily do this, and would
>essentially need to be "ported" to the new toolkit, that or discarded and
>rewritten.

Yep, I do like an idea of dynamic wiring.

>many toolkits and frameworks though are written to assume such a level of
>dependency, and are problematic to try to use in such a way which does not
>in some way significantly impact the app with which they are used, and often
>will not play well with another toolkit which does essentially the same
>thing, since inevitably they will conflict over some or another "prized"
>resource and would step on each other if one tried to use both.

>>> and it "should" be a component which can be integrated into a
>>>project (or dropped again) without otherwise requiring significant
>>>modification.

>>>this is the ideal, although granted, it is much work to achieve these
>>>sorts
>>>of ideals.

>>>>>granted, nothing is perfect.

>>>>>in general, I like C# though, as for the most part it seems a fairly
>>>>>cleanly
>>>>>designed language (apart from that it seems to need some level of "black
>>>>>magic" to be able to parse).

>>>>>I am a little more hesitant about the rest of the .NET framework though,
>>>>>and
>>>>>would rather it was something capable of being statically compiled and
>>>>>operated standalone.

>>>> I just looked at some of it in passing.
>>>> Looks like some kind of equivalent of JVM underneeth.

>>>C# is sort of like "Java's big brother" in terms of design. at its core,
>>>they are in many ways fairly similar languages (just C# returns a little
>>>closer to its C and C++ roots, re-adding many more features and
>>>complexities...).

>> Well, I saw some of that stuff. Never had enough time to get into
>> it. And what I saw does not make that much of a sense to me.
>> Just another pile of complications and bells and whistles
>> that simply make my job MORE difficult and not less,
>> even though they'd take me up on spears for saying things these,
>> lil could I care though. Cause I know where I stand and what I need.
>> Not them.

>>>in a similar way, the .NET VM architecture is sort of like a "big brother"
>>>to the JVM.

>> I bet it is a ripoff essentially.

>historically, probably...

>initially, MS implemented J# and their own customized (and MSified) JVM.
>Sun did not take too keenly to their effort, and so there was a lawsuit.

>shortly thereafter, MS made a new language: C#, which kept much in common
>with Java (but added many syntax changes and new features).

That is what I meant.
I just saw too many Javaish things in C#, the whole MVM concept,
and I bet the whole .net trip is the same thing.
That is why I called them what I did.

And I would not doubt in my mind that they intend to screw Sun
at the end so they could suck in as many people into the webs
they weave and Sun, for obvious reasons, barked at that.
Not sure what I'd do in their place.
But to take upon the microsoft, even if you get paid tons of bux
at the end, was the end of Java, at least to vast majority of
boxes out there. I think ms dropping java is probably the most
monumental move in the entire history of sw industry.

>they also created MSIL / CIL, which shares many commonalities with JBC, but
>also differs in many ways as well.

>>> there are many subtle aspects which are similar, but with one
>>>notable and apparent difference:
>>>..NET is FAR more complicated WRT its internal workings.

>> Well, that IS the very core strategy of Microsoft.

>> What it is is this: whenever you need to do ANY kind of improvement,
>> do it in the MOST complicated way possible. So it takes those goats
>> at least two years to feel comfortable with it.

>> If you need to add 2 and 2, do it in such a way, that you have five
>> layers of abstraction. Plug in universal-trans-gallactic,
>> super duper omnipotent wrapper that won't even run unless they
>> sign YOUR "protocols". Then document it as little as you can.
>> And release it under the slogan of "New Revolutionary Technology"
>> (of suckology).

>yeah, a lot is just hacks and extensions of prior technologies.

>MZ/EXE (from MS-DOS) and COFF (from Unix) were hacked together to produce
>PE/COFF (used in 32-bit EXE's from Win95 and NT4 onwards).

Its a pitty that people who initially concieved and designed these
things did not even get a penny out of it.

It was all repackaged and stamped with "copyright" or "patent" stamp.
Simply disgusting.

I did have some direct experience with MS a while back.
What they asked me essentially is this: you give us your product
for FREE and we will include it in OUR package, the O/S.
And we won't pay you a penny in return.
But you do get to be "approved" by us and we will get more money
as a result of including more and more blood from the people and
companies like you.

I said: screw you and screw your whole trip. No deal.

Those suckers did not even offer a PENNY.
What a disgusting bunch of sickos, sucking blood from everyone
they can get their hands upon.

>then a bunch more crap was hacked on to create MSIL Images, which are
>basically PE/COFF with a bunch of relational tables and stuff added, and
>MSIL bytecode thrown in.

>I also ended up using PE/COFF, mostly for compatibility reasons, but most of
>my metadata notably differs (my metadata is not based on a relational
>structure, but is instead a heirarchical DB, mixed with some other parts
>which are based on a TLV structure loosely similar to RIFF or PNG, although
>by default a bit more compact...).

About the pittiest thing in this whole thing is that people
like Gary Kildall simply get slaughtered at the end, while these
parasites make a killing on the work of others.

>> The square purpose of Microsoft is to get everyone entangled into
>> this gook, and once they are caught, there is no way out.
>> Then attach your sucking tubes to their body and suck as much blood
>> as you can manage. Until they can barely breath and walk.

>> That IS the very core of their "strategy".

>> The same thing is Google, the manifistation of evil even more
>> profound from what I know.

>> Recently I have heard that they have all these zombies running
>> arount the hallways at Microsoft with plastic smiles, stuck on
>> their faces, while thinking about ANY kind of crap they can
>> come up with so it could be "patented".

>> What Microsoft and Google do right now is to try to patent
>> ANYTHING they can imagine. They pay people a few hundred bux
>> if they come up with ANY crazy thing that could be patented.
>> Not that they have ANY plans to actually use thesse "invention".
>> But just to prevent ANYBODY from possibly doing it, and if they
>> DO intent to use it and if they DO invent something, you can
>> claim: sorry, you can only do it if I attach my sucking tubes
>> to your body and suck your blood.

>> The same thing is what Google is doing this very moment.

>> The consequences are simply horrendous. I just thought about
>> a couple of things and I had goose bumps, just to see what
>> could be result of it in my specific situation, even though
>> I don't think their zombies already patented some stuff I've
>> been doing.

>ok.

>>>(the JVM has a few hairy bits, but in general it is "not that bad", and a
>>>beating together a working basic implementation is a "reasonably" easily
>>>achievable goal).

>> Well, good.
>> That is ALL that counts at the end.

>>> well, apart from the persisting lack of a class library
>>>(writing Java code in a vacuum is not nearly so compelling).

>> Well, I even heard some people in Java world complaining that
>> Java has just WAY to much stuff, which should not belong to
>> a language.

>> From what I see, this C# stuff is mostly a ripoff of Java.
>> But that is another matter.

>> Just look at collections. They are rich enough to fill vast
>> majority of applications and their performance is as good as
>> it gets. All the algorithms that I saw are top notch
>> implementations that approach the theoretical limit of a given
>> approach.

>> And that is ALL I want to hear about collections.
>> And if you don't have something that is covered by collections,
>> well, that is what programmers are for. Keeps you gainfully
>> employed after all.

>> In other words, I can not agree with this one.
>> I'd like to see more substance to this argument.

>as-is, I don't even really have "java.lang" in place, and so most of what
>goes on would require plugging into C land

Coolio! :--}

>(and at the moment, likely
>writing far more JNI code than actual Java).
>similarly, it looks like a hassle to plug classpath into my project, as I
>would have to write a lot of machinery to glue it.

>possibly, I could try to go and write some wrappers for some of my C based
>APIs, and then build some of the core Java API's on top of these.

>so far, I have not done much of the sort.

>>>> A single fact that you need to agree with something to even
>>>> have your app to run under it, is a total no go for me.

>>>> You can not even deliver your J# app as a single executable
>>>> is simply berzerk. And now, you can not even compile Java
>>>> starting with VC 2008 and higher. Disaster.

>>>yeah.

>>>>>little in the language particularly prohibits this, only that I am not
>>>>>aware
>>>>>of any standalone C# implementation.

>>>>>it is, at the moment, a little easier to write standalone Java, since
>>>>>there
>>>>>is both GCJ, and JBC is simple enough as to make it not particularly
>>>>>difficult to trans-compile to C or ASM

>>>> Oh, interesting. Is there a way to generate Java code out
>>>> of C++/MFC by any chance?

>>>"there be dragons there".

>>>Java can be compiled to C without too much horror,

>> Well, I am talking about MFC specifically, and that is GUI
>> stuff to a large extent, that works totally different than Java way.
>> I don't think it is a trivial task.

>yeah, probably a real horror that.

>>> since for the most part
>>>JBC uses a clear subset of C's basic capabilities (although, the
>>>translation
>>>is at a fairly low level of abstraction, for example, I operate
>>>"underneath"
>>>the JVM's stack model, and essentially remap stack operations to local
>>>variables via a kind of naive graph-conversion algo...).

>> Cool stuff. Why don't you publish more about it?
>> Some principles, architecture or what have you.
>> If you think you can do it or even interested in doing it...

>it is fairly generic compiler stuff here.
>a JIT is likely to be faced with many of the same issues.

>just, translating stack operations into variable operations is a little
>cheaper than faking the stack, and with JBC's restrictions, does not add
>notably to the complexity.

>a few of the ugly edge cases are mostly that there are a few opcodes which
>assume a stack composed of 32-bit items and make some assumptions WRT item
>size, which, errm, kind of turn ugly when dealing with an abstract stack.

>>>I actually use a plain Java compiler to produce the class files, so that I
>>>could them mostly focus on translating the bytecode to C.

>>>however, C does not map nicely to the JVM (even in the simple case, it is
>>>horridly inefficient, and even more horridly crappy), this much is not
>>>likely worth the bother.

>>>C++ -> Java, if possible, would likely be something too terrible to be
>>>described.

>> Too bad. Well, what to do? I was just trying to see if I could
>> save a couple of months of work if I had not rewrite it by hand.
>> But that's ok. We can live with that.

>> I would REALLY like to port my monitoring firewall to linux.
>> The problems are mostly GUI and low level network driver interface.

>ok.

>>>x86 -> Java or JBC should be possible, but I doubt would be of much
>>>practical use (likely poor efficiency, and the languages would not be able
>>>to really relate or share data at a meaningful level). likewise for just
>>>writing an x86 interpreter.

>> Well, I did not expect to have much luck. But just in case.
>> The stuff does not map from MFC to Java that well.
>> Basically, you have to rewrite the whole thing.
>> But I bet it is going to be the easiest thing in the world,
>> going from C++/MFC to Java. It would probably be 3 times as hard
>> to go the other way around. MFC sucks pretty bad as far as sophisticated
>> GUI goes where you do not use the modal dialogs and where you dialogs
>> are not some dumb, single threaded, fixed size miniscule boxes,
>> just like about anything microsoft does, but are fully resizable,
>> multi-threaded, property sheet/page dialogs.

>> That thing would be a disaster to implement in MFC.

I know. I am still struggling with some totally ridiculous stuff,
just trying to resize some nested GUI stuff. The stupidest thing
in the world and the amount of time I had to waste on it is just
monumental compared to the functionality I was after. That same
thing is a sneeze doing it in java and using nothing more than
gridbag layouts.

>never really used MFC, though had used GDI+ some in the past.
>mostly I use OpenGL and do my own widget drawing via GL, although there are
>drawbacks.

Well, I used it from the day one. Basically, it is just an object
oriented C++ wrapper for win32. So, I started using it as my main thing.
Never regretted it, except when you have some nasty details
and primarily in the GUI end of it, if you are writing some
flexible GUI code.

>>>however, an interpreter would allow, potentially, compiling C++ code to
>>>x86,
>>>loading the x86 in an interpreter and running it (at likely crap speeds),

>> No. Interpreters are totally out of the window for this job.

I mean the firewall app.

>> It is high traffic, high performance situation, where you have
>> to do all sorts of tricks to make sure you are not blown out
>> in some situations.

>ok.

>>>....

>>>is it worthwhile?... probably not.

>>>it is worth noting that low-abstraction machine-code like representations
>>>(including JBC and x86 machine code) are generally easier to translate and
>>>manipulate effectively, whereas with higher-level forms (such as source
>>>code), one can generally do a much better job and has far more "power".
>
>> I don't know what is JBC.

>Java ByteCode.

Oh, Jeez!
:--}

Thats about the last thing I would even think about it.
I thought it is some kind of gadget.

>>>however, JBC can be fairly faithfully converted to C (much easier than
>>>many
>>>other possible paths), and does not tend to introduce all that many
>>>"impedence" problems.

>>>hence, it works acceptably to convert Java to C by first compiling to JBC
>>>(AKA: class files), and then translating.

>> I need C++, and specifically, MFC to Java.

>ok.

>can't much help here...

>compiling code is a much simpler task than converting between API's...

>>>however, this does not extend to the general case, and is very specific to
>>>various internal properties of both Java and JBC.

>>>(although, granted, there are still a few sharp edges, but these are
>>>managable).

>>>for example, Java requires that the stack have exactly the same layout at
>>>both the source and destination of a jump, and that the layout of the
>>>stack
>>>is required to be constant at a given bytecode position.

>>>the implications of these simple restrictions are notable and drastic, and
>>>without these particular rules, doing an effective translation would have
>>>been a much uglier problem (essentially requiring "simulation", rather
>>>than
>>>a value-flow graph-based translation, ...).

>>>just imaging here that every push and pop pushes or pops an abstract
>>>variable, rather than a value, and so the sequence of stack-based
>>>operations
>>>can be compared to putting down and picking up the ends of tubes and
>>>plugging them into operations, and then putting down the result-tube, ...

>>>the process, though naive, is elegantly simple, and can convert a method
>>>from a sequence of stack operations, into a graph of interconnected
>>>operations, which can then be (fairly straightforwardly) converted back
>>>into
>>>C code.

>>>none of this holds with either C, C++, or x86 machine code, OTOH, and
>>>hence
>>>such a conversion is not directly possible as such.

>>>or such...

>> Hey. Good article. I really enjoyed it.

>ok.

What can I say, it is a pitty, society does not support the guys
like you and give them some basic funding just to be able to exist.
Because I think people like you can contribute more to the whole
equation, that most of the big mouths out there, called "experts".

Good luck.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

== 2 of 2 ==
Date: Sat, Dec 26 2009 11:05 pm
From: "BGB / cr88192"

"tanix" <tanix@mongo.net> wrote in message
news:hh6heo$2lo$1@news.eternal-september.org...
> In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192"
> <cr88192@hotmail.com> wrote:
>>
>>"tanix" <tanix@mongo.net> wrote in message
>>news:hh4vpq$304$1@news.eternal-september.org...
>>> In article <hh4fo1$7p6$1@news.albasani.net>, "BGB / cr88192"
>>> <cr88192@hotmail.com> wrote:
>>>>
>>>>"tanix" <tanix@mongo.net> wrote in message
>>>>news:hh3nuq$14q$2@news.eternal-september.org...
>>>>> In article <hh3ne4$7k2$1@news.albasani.net>, "BGB / cr88192"
>>>>> <cr88192@hotmail.com> wrote:
>>>>>>
>>>>>>"Chris M. Thomasson" <no@spam.invalid> wrote in message
>>>>>>news:xR9Zm.3013$8e4.2445@newsfe03.iad...
>>>>>>> "tanix" <tanix@mongo.net> wrote in message
>>>>>>> news:hh31vk$82i$1@news.eternal-september.org...
>>>>>>>> In article
>>>>>>>> <66e7b0f7-4c71-4db4-a9f1-3f9d7e4dc5a5@a32g2000yqm.googlegroups.com>,
>>>>>>>> James
>>>>>>>> Kanze <james.kanze@gmail.com> wrote:
>>>>>>>>>On Dec 23, 11:02 pm, red floyd <redfl...@gmail.com> wrote:
>>>>>>>>>> On Dec 23, 12:50 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>>>>>>>>>
>>>>>>>>>> > The number of job adverts in the UK citing C++ has fallen
>>>>>>>>>> > 40% for the second year in a row:
>>>>>>>>>
>>>>>>>>>> Hey, Jon! Wha'ts the market for F# jobs like?
>>>>>>> [...]
>>>>>>>>
>>>>>>>> Well, I just looked at it on Wikipedia:
>>>>>>>> http://en.wikipedia.org/wiki/F_Sharp_%28programming_language%29
>>>>>>>>
>>>>>>>> Looks like another bluff to me. All sorts of bells and whistles.
>>>>>>>> For me, personally, it is a no go, and primarlily because it is
>>>>>>>> based on .net framework.
>>>>>>>
>>>>>>> FWIW, here is a fairly portable C# and CLR implementation:
>>>>>>>
>>>>>>> http://www.mono-project.com
>>>>>>>
>>>>>>
>>>>>>yep, in my case, I acknowledge that mono exists.
>>>>>>looking deeper into the project though, I am personally a little less
>>>>>>compelled:
>>>>>>it is, IMO, poorly architected and built on terrible code (and
>>>>>>terrible
>>>>>>coding practices).
>>>>>
>>>>> Uggh. That one is going to wait then.
>>>>>
>>>>
>>>>well, I guess it is probably not so bad if:
>>>>one only really expects it to work on Linux, and uses MS's .NET on
>>>>Windows;
>>>>makes sure to pretend (sort of) that they are coding on Windows, and
>>>>stays
>>>>clear of Mono's extensions (mostly GTK bindings, glue into a bunch of
>>>>GNome
>>>>related stuff, ...).
>>>>
>>>>personally, I would have assumed making a new GUI API, which was
>>>>generally
>>>>free of being tied to a particular OS-level GUI. I don't like the idea
>>>>of
>>>>coding against a GTK wrapper, as personally I don't want to be tied to
>>>>having to use GTK.
>>>
>>> Sounds horrible.
>>>
>>>>but, this is not the end of it, as it is worth noting that Mono itself
>>>>is
>>>>tied to GTK at a very fundamental level (IOW, a lot of the core VM code
>>>>is
>>>>built on GTK's API functions, on GLib, ...).
>>>
>>> GUI IS one of the biggest problems.
>>> I had a chance to look at some of those toolkits in passing.
>>> Horrible stuff.
>>>
>>
>>yep...
>>
>>and one can also wonder why parts of the core VM (JIT, PE/COFF machinery,
>>....) need to be dependent on GTK and GLib (using GObject, ...).
>
> Well, at least I do not have to worry about it.
> Probably for historical reasons. After all GTK is one of the oldest
> toolkits around.
>

yeah.

>>granted, I guess there is a partial solution, which is to use basically a
>>stripped-down dummy version of GTK for building the VM, but I dislike this
>>having been needed in the first place.
>
> I am not sure how easy it would be to do it with something else.
> After all, almost anything I saw in terms of graphics on Linux/Unix
> looked to me like a nightmare.
>

this is not even for the graphical code.
if it were only the graphical code, I would have less reason to complain
about it...

> What a pitty.
> I do not claim I am aware of all the "progress" that has been made,
> but I think it is one of the weakest points of Linux/Unix.
>
> Furthermore, from what I recall, it is not even a single layer
> of abstraction. There is this dinasaur X11 stuff and on the top of it
> some GTK and on the top of that is Gnome if you are talking the O/S
> level user interface. But I am exactly a reference point on this.
> I did try to look at some graphics related stuff, but every time
> I had goose bumps just trying to figure out what is what and who is
> who.
>

yep, except that on Windows GTK can work via GDI (though it does so in a
very X11-like manner, namely creating a window and dumping graphics into
it...).

I just dislike GTK though as it has a bad habit of not really working on
Windows (as well as not exactly being a very clean API).

X11 abstracts over the graphics hardware and facilitates multiplexing and a
"window manager".

>>> I think there needs to be some portable GUI subsystem so you don't have
>>> to worry about one toolkit on one platform and totally different way
>>> of doing it on another.
>
>>agreed...
>
>>sadly, the best option in Mono's case is "Windows Forms", if anything
>>because it directs to GDI on Windows and GTK on Mono.
>
> Windows forms immediately triggers the visual basic syndrome in me.
> :--}
>
> But what I do have to agree that it is pretty easy to graphically
> design some of your GUI stuff with it. But that is about all the
> good news about it.
>

yes, ok.

>>> Something like it is in Java for example.
>>>
>>> Otherwise, they keep reinventing the wheel and none of it you can
>>> rely upon as a single version of your code.
>>>
>>> Unfortunately, you need some equivalent of JVM to do it to shield
>>> you from the O/S particularities.
>
>>one can get "halfway there" via clean coding practices.
>
> Well, may be. But when you start from scratch, the curve is too steep
> in terms of time and effort for you to get something realistic done.
>
> It is much easier to rely on things like swing or even awt.
>

granted, but it is not so bad when after one has a 10+ years old codebase,
and so most of the basic stuff is already working. granted, there are good
and bad points here.

>>> But I think we are at the point where things like JVM or MVM
>>> or that sucky .net are essentially what virtual machines are.
>
>>> Processing power and memory limitations are no longer there.
>
>>but, it is not good to waste them either...
>>many of us do write code where performance matters, and where seemingly
>>very
>>little issues in the right spots can eat lots of clock cycles or memory...
>
> Yep. No questions about it.
> But at least if there was some lanugage facilities you could rely upon,
> the stuff under the hood could be optimized as it forever happens.
>
> I am not sure how much of a performace factor the GUI code would
> be dependent on. Some key listeners, some event listeners, the async
> processing and things like that.
>

yeah.
one of my annoyances with the JVM though is using UTF-16 for character
strings, since this makes strings-heavy code waste memory (I personally
prefer UTF-8 for most things).

> I have pretty large dialogs I would say, probably with at least 50
> components,
> and in some cases 3 times as much. Never ever felt any kind of performance
> issues with it. Sure, if you do real time graphics or 3D app, that could
> be a totally different story. But I have no clue in those areas.
>
> As long as it is not a real time stuff, I doubt GUI is subject to
> performance issues.
>

I do both 3D and soft-real-time apps.
in some kinds of apps, performance is fairly critical to usability, as lag
makes the app unusable.

>>> It is understood that at a time of P-Machine (Pascal), which was meant
>>> to significantly improve the performance of Pascal, it was unrealistic
>>> to expect that the idea will be accepted, and it was not.
>>>
>>> But now things are different.
>>>
>>> Basically, the portability, a single way of saying something,
>>> without worrying about the O/S, environment or anything for that
>>> matter is what is needed more than anything else.
>
>>I disagree in the strict sense.
>>if the code can be rebuilt easily enough for the various target OS's, this
>>is often "good enough".
>
> Fine with me. I am willing to take a source level portability.
> For as long as I don't have to give an arm and a leg to sharks like
> Microsoft or Google.
>

ok.

>>virtualization can help, but usually it is far from free either.
>
>>for example, neither JVM nor .NET will allow one to use the same code for
>>both a hosted and native build, and IMO this aspect is important as
>>well...
>
> Well, I am not even dreaming of that level of portability.
> At the moment, we are just totally empty handed.
> And if it takes several years for those "committies" to come up to some
> kind of agreement, I'd rather take at least some of it, if it can be done
> "real soon now". As long as they are not going to change it every day.
>

ok.

>>granted, if I compile a bunch of Java to a native EXE or DLL, it can't
>>really be expected to run on, say, Linux, but this much is not the issue.
>
> Yep. Source level compatibility AND the ability to compile it to
> a natural way things are executed on a given platform, is fine with me.
> Actually, that was my argument with Java guys a while back.
>
> I said: when I run a windows app, I expect it to be an .exe file
> that I can simply click upon to run the app. Because THAT is the way
> every runs under windows. Everybody knows it, and everybody is used
> to it.
>
> I do not even want to know that there are some funky portable .class
> files underneeth, and those are the actual things that run.
>

yep.

> And this is a fundamental conflict with the very concept of ?VM.
>
> Because if you simply want to have an exe, then, by definition,
> you need to compiler your ?VM either into a single executable,
> or executable that simply loads some dll.
>
> And that kinda breaks the whole idea behind the JVM at least
> since class files are your final "executables".
>
> JVM executes a pseudo code, not a native mode code.
>

it would be nice to have an option is all, especially for mixed Java and C /
C++ apps.
at present, mixing Java and C code is "not exactly nice", which is sad...

it would be nicer if, say, one could write parts in C, and parts in Java,
and not have to worry about using magic rituals needed to get them to play
together.

>> it
>>would be better if one could compile it in both cases, rather than
>>creating
>>yet another barrier:
>
> Totally agreed. I want to see it compile into a single native mode
> app that may or may not use the dlls under windows.
>
> But then I am not sure how would you go about with the very
> concept of ?VM.
>

well, not all VM's are the JVM or .NET style.

consider the Python VM:
the main part of the app is typically C or C++, and then it links against
the VM, which in turn loads python scripts or bytecode files.

the goal and use case is very different, and my VM is, in many respects,
closer to the Python VM (in purpose) than it is to the JVM.

so, there is a cost:
my strategy does not allow avoiding rebuilding an app for various target
OS's;
it is a tradeoff, but it is acceptable enough for my uses.

although, it is not mandated by my design, this is just how I am currently
using it (otherwise, I would have to migrate much of the codebase to run on
top of the VM...).

>>Java code is, always, run in the VM;
>>native code is C and JNI.
>
>>there are at least several JVM's which ended up allowing running the C
>>code
>>in a VM as well (just x86 based rather than JBC), but still using JNI to
>>interface them.
>
> I am sure there are ways to solve these kinds of issues.
> Exept everybody is busy erecting the castles on a see shore
> from what I see.
>
> Again, I am very displeased with the direction of language
> development in general, no matter where you look.
>
> I think is is a totally dead end approach.
>

worth mentioning here is LiquidVM, which runs both Java and C in a VM.

no new language is created here.

> They are not even looking at the most critical issues to a developer,
> and "could care less" about what is happening in the world in terms
> of it being more and more dependent on the information processing
> aspect, such as web.
>
> I doubt what people need is some "revolutionary" syntax.
> Have not seen ANYTHING that excites me in F#, even though it looks
> nice on paper. I have not seen things like GUI, threads or GC
> even mentioned.
>
> Why do you think PHP, Python, Ruby, Javascript, SQL and even HTTP
> are so appealing.
>
> Vast majority of web based apps are developed with PHP from what
> I see. Most of CMS systems, bulletin boards and you name it use PHP,
> even though Python and Ruby have much higher performance.
>
> Just look at the very central idea of PHP that you can mix
> your html code with php, however crazy it may sound, and it does
> sound crazy to me. But it gives people so much power and flexibility,
> that any kid cad deveop something working within days, even though
> they might have never heard such things as synchronicity,
> threading, acync processing events and things like that.
>
> And THAT is what is happening in the world, and I bet you,
> it is going to be happening more and more.
>
> People do not even know about the portability issues.
> Because they simply do not exist.
>
> They could care less if you run JVM or anything for that matter.
>
> They don't care how "pure" is your syntax and notation
> from the standpoint of some "head".
>
> They do not know what means static binding or dynamic binding
> necessarily.
>
> And yet, there is a tremendous amount of work being done
> and it does what they want.
>
> Why not look at it as an opportunity?
> Especially if you have the underlying principles that allow
> you to run orders of magnitude more efficiently?
>
> Why not look at THESE things instead of sitting in an ivory tower
> and keep inventing some new mental perversion that will make
> people shiver when they look at it?
>

errm...

I am not trying to build a "new ivory tower", as I already dislike this
strategy...

more, I am building stuff to do what I want to do with it...

I have no new language, no fudamentally new architecture, ...

actually, it is a set of very conservative designs, in that nearly every
part is based on things that are already fairly well established, such that,
for the most part it is invisible.

once as a joke, I considered calling the whole VM project "Silverfish", and
went as well as to make a glossy metallic logo image for this (depicting one
of these critters partly in a circle).

the idea is a VM more like the silverfish, which lives in ones' laundery and
eats lint and stuff...

however, in general I call it 'BSCC'.

>>> I personally think F# is a flop, no matter how many people join
>>> the camp. It is a convoluted, over complicated pile of concoctions
>>> that try to give you all sorts of bells and whistes to the point
>>> that they even try to address the database issues and do some
>>> hacks of Javascript level where functions may include other functions
>>> as parameters. It is a mix of Lisp and Javascript. Essentially
>>> the same idea of dynamically built code. Except complexities
>>> and the very concepts are as flaky as it get from what I see.
>>>
>>> Building a dynamic code that can go as far as dynamically construct
>>> some other code is not exactly a new idea, going back to Forth,
>>> Lisp, etc.
>>>
>>> But the very concept is flawed. The code becomes utterly unintuitive.
>>> You can not even comprehend what comes out of it at the end.
>>> I talked to Javascript guys and they said once you hit a certain
>>> problem related to this kind of stuff, good luck. Because it is
>>> going to be a hell for you to fix it and you may have to spend
>>> months on it. I'd say I agree after looking at Javascript.
>
>>yeah.
>>dynamic languages tend to have a certain limit to their scalability.
>
> For one thing. Except you need at specific app.
> If it is a server end, yes, there is a need for scalability
> and performance, and I think Java solved it quite nicely.
> Not saying it is the "ultimate" solution. Because none exists in
> principle.
>

yes, ok.

>>some of their abilities are really nice and powerful at the small scale,
>>but
>>the bigger a project gets, the harder it gets to manage.
>
>>many static languages tend to scale much better.
>
> Sure they do. That is the whole point of them.
> And that is why I'd like to see a STATICALLY scoped (typed :--})
> languages to at least consider the modern world.
> Because they don't even bother about anything else, but their own
> lil sandbox in the scheme of things.
>

well, they work fairly well for what they do.
static languages make up most of the code which does actual work;
and dynamic code usually does specific tasks for the benefit of a particular
app.

it all works out well enough I think.

>>my intuition here is that probably C likely scales fairly well (if
>>practices
>>are good), with C++ and Java likely comming close (again depending on
>>practices, Java will likely allow scaling easier at the "medium" scale).
>
> Except it is used on the largest scale in banking, finance,
> wall street, governments, etc.
>

ok.

>>JavaScript is not likely to scale well.
>
> Well, it does not need to. It is a client end gizmo.
>

it is also gaining popularity in non-browser settings...

>>guestimate:
>>C (with poor practices), likely to turn into an ugly mess at around 30-50
>>kloc;
>>C++ (with similarly poor practices), maybe around 50-75 kloc;
>>Java (with 'generic' practices), likely at around 200-400 kloc.
>>
>>in C and C++, the user is likely to end up stumbling around with globals
>>and
>>memory objects...
>>
>>in C++, the limit is likely to be a slight bit higher, due mostly to the
>>programmer trying to naively use namespaces, classes, and RAII as "magic
>>pendants".
>
> I like this one:
>
> "only real danger is that we simply forget to release the resource,
> which, while it does happen, is something that should be quickly caught
> in any code-review."
>
> What a joke!
>

yep.

>>this would work for a little while, but ultimately these can't
>>save poor practices (for example, a global in a namespace is still a
>>global,
>>....).
>
>>by adapting many coding policies, the situation is reversed, very
>>possibly:
>>C (good practices), ~ 1 Mloc;
>>C++, ~800 kloc;
>>Java, ~ 500-600 kloc (?...).
>
>>reasoning:
>>in C, one is likely to have learned early on that fairly rigid coding
>>practices are needed to help code scale, and if followed make the natural
>>large-scale structure somewhat different from its smaller-scale form.
>
>>C++ is similar, but I suspect it is likely that there will be some
>>"aliasing" related to misusing some OO features in ways which create
>>"tangles" (very likely, the same features which tend to help at the
>>smaller
>>scale).
>
>>actually, from my experience, a sufficiently large C or C++ project is
>>likely to start notably resembling an existing OS, such as Linux or
>>Windows
>>(or at least, this was my experience...).
>
>
>>Java is not likely to help, since the language itself has a fairly
>>restrictive design, and it would be awkward to use a large-scale
>>architecture in conflict with the languages' built-in architecture. I
>>could
>>be wrong though, not having had much significant experience in the
>>language.
>
>
>>JavaScript is not likely to scale well much above maybe 10-25 kloc, and
>>attempting to adapt modular practices would make the language likely
>>somewhat unappealing.
>
>>the advantage if offers then is that, given it is likely to be used for
>>scripting rather than for infrastructure, code is likely to be small and
>>divided up into disjoint islands, which would help keep issues
>>more-or-less
>>contained (the number of such islands should not be a significant factor
>>beyond the level of code one has to deal with).
>
>
>>> A while back, I had the same idea, except it was for database
>>> applications. I asked a question: what prevents you from writing
>>> a database stored program where you use the rows to store your
>>> high level instructions? Well, nothing really. I implemented in
>>> and it worked just fine. But then it withered away. Basically,
>>> I stopped working with database.
>>>
>>> Now they have it all over the place.
>>>
>>> But there are plenty of disadvantages of such an approach.
>>> It lacks the necessary structure. Yes, it is as portable as it
>>> gets, but you don't have that "super-language" syntax. It is
>>> all disassociated set of instructions, no matter how high level
>>> and how powerful they are. It lacks the properties of high
>>> level languages.
>>>
>>> So, my opinion on this is that people think "it would be nice"
>>> to add the ability to construct the programs. But they seem to
>>> fail to comprehend that your very language becomes a nightmare
>>> in the modern world.
>
>>ok.
>
>>> Again, people do not have neither time, nor interest to waste
>>> hours of their time to either read some complicated goubledy
>>> gook code, that takes hours just to understand what it does
>>> essentially because of the most horrible, utterly unintuitive
>>> language syntax constructs, and I specifically mean generics.
>>>
>>> When and why do you need generics and what does it buy you?
>>> Well, I can find only one place in my code, and that is a relatively
>>> large piece of code, where "generics is a must". Lucky me,
>>> I can not even use generics because it is not supported in
>>> my development environment, thanx to these wars between
>>> Microsoft and Sun.
>
>>newer Java does support generics, FWIW.
>
> I know. Except VS 2005 is the last version of IDE that supports
> Java syntax. Beyond that, there is no concept of anything even
> remotely related to Java. Thanx to these Sun vs. Microsoft wars.
>

ok.

>>> So, I had to implement it using the "copy/paste antipattern" and
>>> I have about 3 copies of exactly the same logic, dealing with
>>> 3 types or argument.
>
>>> Do I regret it? - Nope. Not to the least.
>>> Did I EVER have ANy problems with it? - Not that I know of.
>>> I don't even notice this code. Works like a champ.
>>> And each of those methods take about 10 lines of code.
>>> Why would I bother to write some ugly code using generics?
>>> I would not even THINK about such a think. UTTERLY usesless.
>
>>> How many places in your code do you have that do very similar
>>> things? Well, I bet ALL over the place. Would you need to
>>> replace it with generics? Well, try.
>>>
>>> One professor from France, a while back said:
>>> Writing programs automatically is just a myth that will never
>>> happen. Because each program is unique and has millions of
>>> nasty little things that distinguish them from something
>>> similar.
>>>
>>> Otherwise, we would not have a software industry by now.
>>> It would be all generated by the software robots.
>>>
>>> And with all the "developments", interfaces, OO approach,
>>> it is still a myth, just the same.
>>>
>>> I do not think THIS is the priority of development and THIS
>>> is what is going to imporve the sofware design.
>>>
>>> And I do not think that introductions of more and more
>>> complexities into syntax and notation is going to solve
>>> ANYTHING. It is just going to create more and more headaches
>>> as it becomes more and more unintuitive.
>>>
>>> Language designers seem to be totally oblivious of the fact
>>> that their language is not exactly what is going on in the
>>> programmers or designer's mind. They need some specific
>>> JOB to be done. Some specific CONCEPT to be implemented,
>>> some specific ARCHITECTURE that will do such and such.
>>>
>>> They could care LESS if your obscession with languages means
>>> something to you as language designer. I do not recall many
>>> cases, if any, where I thought: oh crap, I can not do this
>>> and that because my language SYNTAX is screwed up, or my
>>> espressive power is not enough.
>>>
>>> But I do recall TONS of cases where I had to waste almost
>>> half an hour of my time looking at some utterly ugly code,
>>> written by some idiot with complex of inferiority, that
>>> probably wasted DAYS of his time to write some generics
>>> goubledy gook code that was not even needed to begin with.
>>>
>>> I could do exact same thing with funken C code, not even C++.
>>> And the hell would sooner get frozen before they can prove
>>> ANY advantage of that "purist" code and all those compile
>>> time "benefits" they get out of it.
>>>
>>> But no. These suckers need to show the whole world how "smart"
>>> they are. You see, they can OUTSMART you!
>>> :--}
>>>
>>> What a bunch of sickos, utterly brainless idiots, driven by
>>> the complex of inferiority, forever trying to prove everybody
>>> how "smart" they are. Why do you need to even bother with such
>>> foolish things? I simply can not find a bettter term for it.
>
>>....
>
>>>>I at first put some effort into trying to get it to build from sources
>>>>on
>>>>Windows, but was having far too many difficulties, and personally found
>>>>the
>>>>code a bit nasty, so quickly enough gave up.
>
>>> Hey. Thanx for your feedback. That is exactly the kind of thing
>>> I need to hear. The last thing in the world I am interested in
>>> wasting weeks, if not months of my time just to eventually realize
>>> I was screwed again by some fools, selling me pussy in the sky with
>>> diamonds.
>
>>>>I later started looking into writing my own .NET implementation, but
>>>>this
>>>>petered out, as my frameworks' architecture started taking shape on its
>>>>own,
>>>>but is not a whole lot like the .NET VM.
>
>>>>actually, my project is a lot more of a chimera (some parts influenced
>>>>by
>>>>the JVM, others by .NET, others by GCC, others by LLVM, ...).
>
>>> Well, would be interesting to see what kind of thing you came up with.
>>> You can write an article on it. Don't worry about that "off topic" crap.
>>> We'll fight if we have to.
>
>>well, for the most part, it is not particularly "compelling".
>
> So what?
> You did spend some time thinking about these things.
> Don't you think that the results of it is worth some value to others?
> And even if you are "wrong" and they jump on you in bulk,
> what is "wrong" with that? Who knows, may be some new insights
> may come up out of it, for you and for them?
>
> I do not think it is such a good idea to simply let your work
> go to waste because you are aftaid of being condemend.
> Screw that stuff. One of the most pitiful things.
>
> I think if you have done some work, it is imperative you talk about it.
> It may generate new ideas for others and for you, just be the shear
> fact that you EXPRESS it. Take it from subconscious level to conscious.
>
> Do not underestimate the significance of it.
>

ok...

maybe a paper of rational and design explanations?...

>>it has nearly all of the parts of a traditional compiler:
>>preprocessor, frontend, IL, codegen, assembler, linker.
>
>>the input language is C, the IL is a little funky (and obscure Forth or
>>PostScript like language, sent between stages in a textual form), the ASM
>>is
>>essentially a variant of NASM / YASM style syntax;
>>the assembler produces COFF, and the linker accepts COFF.
>
>>it "may" use a custom name-mangling scheme, which is largely a hybrid of
>>JVM/JNI naming, and IA-64. basically, it combines a lot of the notation
>>from
>>IA-64 with the general syntax of JVM signatures, and then converts it to a
>>linker symbol with a convention based on that used in JNI (although, it
>>has
>>special-cases for several additional characters, as well as a shorter
>>escape
>>for chars in the 1-255 range).
>
>>this particular type-signature scheme is used by many internal components.
>
> Look, I can host your project and ANY documentation you have.
> We'll make a separate "site" for it that contains the interesting
> projects in the area of language or system development.
> You'll have your own top level link that will be shown in the
> top level index.
>
> That is what I can do.
>
> This should not go to waste in my opinion.
>

well, I have some stuff here:

http://cr88192.dyndns.org/bscc.html

it has a general rationale, a partial spec of some of the data, and some
project dumps (most recent from around 4 months ago...).

>>> however, I think its only real advantage is that I personally feel the
>>> role
>>>>of the VM is different, and so there are many "philosophical"
>>>>differences.
>
>>> Like what?
>
>>both the JVM and .NET want to remake the world in their own image,
>
> YES.
>
>> and set up "the one true VM to rule them all".
>
> Well, except in case of microsoft, you'd have to say
> "to rule them all as long as you are dealing with OUR stuff".
>
> That makes a difference.
>

yep.

>>I disagree with this strategy.
>
>>a VM is, IMO, "a framework" not "the framework".
>>hence, in this sense, I am a little more closely aligned with Python or
>>Lua.
>>(although, I personally don't have so many happy feelings towards Python
>>either).
>
> The only thing that prevented me from geting into Python,
> even when I needed to, was abscence of braces.
> The very idea of using white space as indentation level is bizzare.
> Just this single thing was enough to stop even bothering with it,
> and when I read his arguments on WHY did he do it, it was just
> a bad joke to me. To try to fit as much code on your scren as you
> want by simply removing the most stable code block delimiters,
> is simply insance.
>
> On the top of it, when I read some of original documentation,
> it seems like the guy has difficulties with comprehension skills,
> jumping right into middle of such nasty things like regular
> expressions and not being able to explain every step of the way.
> Some syntax issues with regex are totally unintuitive.
>
> Some other stuff like installation subsystem borthers on insanity
> to me. When I looked at documentation, it was just like reading
> a bible sized book with ALL sorts of blabber, just to copy some
> stinky files around and set up some relatively simple things.
>
> As a result, full stop on Python. Regardless how many people
> say it the the solution to mankind's problems. Python is hack.
> I like "real" languages developed by people, who has seen it
> all in and out, and not by some smart "wizards".
>

granted, yes.

I don't so much like the Python language, but I suspect my goals are a
little more closely aligned, granted, the technology is itself a slight bit
different...

>>> You see, what I am beginning to sense more and more that the solution
>>> to language and portability issues is that very VM as a concept.
>>>
>>> And I think Java is a perfect example of it.
>>> Because it demonstrated in practical terms that the whole language
>>> becomes much more powerful (in my opinion) and MUCH more portable
>>> and all sorts of portability related issues could be resolved,
>>> and GUI, threads and garbage collections could be wired right into it.
>>>
>>> So, once you have a VM that handles all those nasty details,
>>> you are shielded from ALL sorts of problems and issues.
>>> Yes, that VM probably have to have some web related functionality
>>> wired right into it. Plenty of people complain about very primitive,
>>> low level support for web apps in Java, and I trust what they say
>>> and I can see some of it, and I think the language and VM
>>> designers need to pay MUCH closer attention to what they ask for,
>>> instead of inventing some ugly even even more complicated stuff
>>> with language syntax and semantics, that turns out to be some
>>> of the most useless thing at the end just because no one really
>>> needs it in forseable future. It all just adds to conceptual fat
>>> at the end.
>
>>yep.
>
>>well, there are merits to VMs, and there are costs...
>
> I'll take the merits and accept the costs.
> What other options do I have?
>

granted.

>>I don't personally believe in aboloshing the JVM, only that I think the
>>way
>>the overall architecture, and the way Sun is managing some things, are not
>>quite so ideal.
>
> May be. But I'd be REALLY careful making these kinds of statements.
> But if you have a better idea, why not?
>

well, as noted, I don't intend to abolish it.
instead, goals can be addressed partly via alternative implementations which
address alternative use cases, but which allow for architectural
differences.

examples:
Apache Harmony (different workings and internal organization);
GCJ (native code support);
Dalvik (essentially a different VM technology);
...

granted, Suns ideal can only be universally true if there is a universal
implementation, which at this moment is generally held to be Sun's JVM.

similarly, Sun has historically tried to be fairly "Iron Fisted" with
maintaining this status quo.

this is the extreme opposite of, say, C, where there is no such
implementation (MSVC is no more "the true C compiler" than is, say, "GCC").
there are standards, but a standard is neither a reference implementation
nor a direct authority figure.

however, if it is allowed that implementations freely diverge and only
remain compatible by consensus, then one can no longer claim that apps are
entirely portable, "lowering" it to the level of C (which is often demeaned
by supporters as being a low-level and generally unportable language, ...).

so, most of this is a lot more philosophical and political than
technological.

one can actually leverage a very large amount of power from otherwise small
details, or waste huge amounts on effort on something which hardly amounts
to much of anything.

>>granted, not everyone has the same needs or ideals, and what the JVM
>>addresses are a slightly different set of ideals than those I am trying to
>>address.
>
> And those are?
>

some want a portable platform, and others want to script an otherwise
native-code app.

some want high-level scripting (JavaScript and Flash), whereas others want
app extension and high performance (such as LLVM).

in my case, I mostly want high-performance, app-extensions, and scripting.

the platform is not, however, an icon of universal portability (as is, my
project would fail miserably on this front...).

>>granted, Apache Harmony and GCJ are both pseudo-JVM's, both of which adapt
>>both Java and much of the JVM architecture, but each varies in some
>>notable
>>and fundamental ways:
>
>>Harmony seems better adapted as a script VM (for example, for the Apache
>>web-server);
>>GCJ can compile Java code to native machine code and link fairly directly
>>with C++.
>
> Oh, now I remember about that GCJ thing. I think I looked at it
> a while back, just in passing. At that time, I did not believe
> they are really selling something real and I did not have any first
> hand experience with it. So I had to abandon it.
>
> Is it something worth looking at in your opinion?
>

well, if one is using GCC and C++, it is probably an acceptable option.
otherwise, these are its main merits.

I think it is fairly "hit or miss" WRT its class library, and only really
works "impressively" on Linux (mostly because on Linux, it offloads a lot of
the "heavy lifting" to Eclipse, but on Windows the Eclipse components are
not present, and so what it implements is a little less complete...).

it should be fine though if one does not demand that generics work, or that
one has a generally complete class library...

>>what the JVM offers is OS abstraction via a virtualized architecture.
>>granted.
>
>>some people don't need this though, and instead want a good scripting VM
>>under the control of a host app, which is a role thus far best filled by
>>Python and Lua.
>
> Well, then have two VMs. I could care less for as long as I know
> when I do this and that, I have to type a different command line,
> or something like that.
>
> You keep mentioning Lua. Have no clue about that one.
>

Lua is basically a simplistic VM for a vaguely Pascal-like language.

http://en.wikipedia.org/wiki/Lua_%28programming_language%29

it competes some with Python, where Python is much bigger and full-featured,
and Lua is a lot smaller and light-weight.

>>another need is for good performance and powerful app extensions, which is
>>better filled by C (high level script languages are good for scripting an
>>app, but not so good for extending it).
>
>>I have some hope of being able to have JVM features available as well, but
>>my motivation has been lacking (the JVM facilities I have in place are
>>not,
>>what I would call, "usably complete").
>
>>many notable VM features (such as exceptions) don't work, and I don't have
>>a
>>class library (there was some attempt to port over GNU classpath, but this
>>petered out some and I have my doubts about using such a massive GPL'ed
>>component).
>
> :--}
>
> Yep, massive seems to the point.
>
> Well, not sure what you have been cooking there and why did you
> have to design your whole world to do things, but I guess you had
> your own reasons to do it this way.
>

well, it doesn't seem like nearly so much when one starts out...

it was a whole world of implementing one feature, then the next, ...
until years of effort have been eaten up and one has some huge monstrosity
of a codebase...

I did not plan this all at the outset, it just sort of turned out this
way...
it is always, at the moment "well, this looks cool / useful / ..., I think I
will implement it".
many steps along the way were, as well, missteps and severe miscalculations,
but oh well...

>>>>personally, I rather dislike monolithic architectures. and so, much of
>>>>the
>>>>architecture is based around loosely coupled "modules" or "components",
>>>>and
>>>>some effort is put into making these compoents too specific, even to
>>>>each
>>>>other.
>
>>> Sure, why not?
>
>>>>so, my beliefs here are that:
>>>>the world does not revolve around the VM, the VM framework should
>>>>"assist"
>>>>the app, not "dominate" it;
>
>>> Well, it does not have to DOMINATE it.
>>> But it CAN assist it, so you don't have to worry inventing another
>>> language to use some of those things, so necessary from the standpoint
>>> of portability, such as GUI, filesystem layer, threads, GC and other
>>> basic and universal mechanisms, needed by just about any app out there.
>
>>> I don't think you can even argue the case of VM being "evil"
>>> even on an embedded system, even though that is a stretch.
>
>>well, I am one of the rare VM developers who is probably not promoting yet
>>another new bytecode or programming language...
>
> Well, I am not exactly an expert in this area.
> Never quite grasped the idea behind the bytecode.
> If someone tells it to me in few words, find, I'll look at it.
>
> What is the primary motivation behind the bytecode?
>

the bytecode is some binary representation of a compiled or semi-compiled
program.
it is closely related to an IL (Intermediate Language), except that an IL
may refer to any number of possible representations (such as text and tree
structures...), whereas bytecode is usually much more specific: a stream of
individual byte-based opcodes which drive an interpreter or a JIT backend.

http://en.wikipedia.org/wiki/Bytecode

>>for some things, I am using JBC, and for other things I have adopted
>>32-bit
>>x86 as a "bytecode" (good and bad points exist here...).
>
> You seem to be gettin to deep into those nasty details.
> Like designing your own world from the O/S level and up.
> I wonder WHY do you need to poke THAT deep into this stuff.
> Is there are philosphical reason behind it?
>

because I built it all from the low-levels and work upward...

I don't personally seem to either think "top down", nor about the distant
future (I suspect my "future" usually tends to be maybe a few days or weeks
or so, then it is all in the land of vague uncertainties...)

I just keep going on and stuff happens, although why and how, I don't
know...

none the less, I do have opinions, and what stuff tends to happen (at least
as far as projects go), tends to somehow / magically go in about the
direction I would want it to go, so no real need to complain too much I
guess.

except that in some areas, very little tends to happen (my code goes
forwards and gradually gets more "impressive", but mostly just bigger), but
other aspects of life, not so much.

how I see progects, and how I see the world, is mostly what all I have
already done, and my memories of how it all works.

even though I have been surprised in a few cases, finding that my memories
of long-past technical trivia sometimes differ in surprising ways from the
actual facts (usually though, this has tended to be order transpositions,
such as which order items were placed in a struct, or in an array, ...).

for example, I had fairly solidly remembered Quake1 having used "pitch,
roll, yaw" angle ordering, yet checking back on the code (after issues with
Quake2) I had discovered it to be "pitch, yaw, roll", and I was at a loss to
explain why. another such difference had been in the coordinate-space
organization, where I had "clearly" remembered 'X=right, Y=forward, Z=up',
but had found
'-X=forward, Y=right, Z=up'.

>>currently C and Java are the main "script" languages in use,
>
> SCRIPT language?
> :--}
>
> I like that one!
>

yeah, they are not designed as such, and not traditionally used for these
purposes, but I use them for these purposes...

going back a few years, I was like "hmm, if I kludge this here
JavaScript-like script-language interpreter of mine with JIT capabilities
into compiling C, I can so totally not need to go through all the usual
hassles of a FFI".

in retrospect, this may have been a very ill-founded idea (it has resulted
in FAR more needed effort in the long run than it has saved).

but, OTOH, it has reduced most of my scripting dillemas to "just use C", so
I guess it pays off...

>> however, I
>>can't currently compile Java on my own (I have ended up having to resort
>>to
>>GCJ to do the first-half of this process).
>
>>I did try to plug Java support into my C frontend, but this turns into a
>>big
>>mess, as my compiler backend can't really deal with Java's constructs
>>(trying to shove C and Java through the same compiler backend is not
>>nearly
>>so easy as it would seem).
>
> Oh, maaan! You must have some royal amount of free time
> to dig THAT deep into it.
>

current running rime on this whole compiler mess:
~ 4 years now (actually, more about 3.8 or so...).

I had gone from the point of having the idea of a C compiler, to having it
working, in about 6 months (initially, I thought it would be a few weeks or
similar). subsequent years, mostly piles and piles of hacking on it
(eventually supporting x86-64, then adding Win64 and SysV calling-convention
support, ...).

the project sort of has a baloon-like inflation pattern...

>>I may instead switch to an alternative strategy, and maybe get around to
>>writing a Java compiler which produces JBC / "class" files,
>
> Jeez!
> :--}
>
> I feel sorry for you. What a task!
>

possibly, but I can probably reuse enough code that it "should" be more a
task of hackery...

as-is, I already have a C-compiler frontend (partly hacked for both Java and
C# style syntax), as well as a "Jasmin" clone, so going direct would likely
be less of an issue than trying to force Java through my backend.

"should" be mostly rewriting the frontend to produce Jasmin-like output,
rather than RPNIL output, and using said jasmin-like tool to produce
bytecode and class files (actually, I would probably ram it together with my
JBC interpreter, since it has a class loader which would also be rather
useful in this case).

or, IOW, force a few parts together, do some ugly hackery with the
internals, and, presto...

>> and then make
>>use of my JBC interpreter, or a translator, for plugging this into the
>>rest
>>of the VM.
>
> Are you trying to reinvent the software busines?
> :--}
>
> Your own VM, your own language, your own interpreter, your own translator.
>
> Maaaan!
>

it is all stuff which piles up...

each part is not nearly so amazing in and of itself...

>>my JBC -> C translator had been mostly so that I could compile Java into
>>native DLL's via MSVC (mostly to avoid having to send it all through the
>>classloader, getting better performance, ...).
>
> EXACTLY what I'd like to see.
>
>>however, issues popped up which stalled this effort.
>
>>the result is that Java has not made "significant" inroads into my
>>codebase,
>>and so C remains as the primary VM language (as well as the implementation
>>language).
>
>>I am still left with doubts though, and if it goes anywhere may end up
>>either using Apache's class library (instead of GNU ClassPath), or maybe
>>writing my own mini class library ("java.lang" and maybe a few other
>>areas,
>>but leaving out most of the rest).
>
> Well, I definetely think you should organize your material
> and make a good site to publish your findings.
> You never know, you might find some other people, crazy enough
> to join your club.
>

yep, dunno...

>>similarly, finding a "better" option than JNI could help (VM-based scripts
>>using JNI just seems horribly tacky...).
>
>>>>it should be possible to use which parts are needed, and discard the
>>>>rest
>>>>(or supply alterantive implementations, if this is needed);
>
>>> I totally agree. Dynamic system wiring is probably more beneficial
>>> than most of bells and whistles I see.
>
>>yep.
>
>>this is all more a matter of coding practices and architecture though,
>>rather than any particular features.
>
>>often, native OS-level API's do this far better than nearly any VM I am
>>aware of.
>
> Fine. So make a thin interface layer above it.
> But make it platform independent.
>
> What I, personally, want is a SINGLE way of writing something.
>
> I want platform independence in STATICALLY scoped (typed :--})
> languages. No matter what anybody says, I am still very hesitant
> to jump into these dynamic languages. I did look at some of it,
> but my heart is somehow not at rest with it. It says: nope,
> it is a trap. Don't go there.
>

yep.
my past experience is that code ends up turning into dirt.
one can write it quickly enough, but it likes to blow away in the wind.

C is more like rocks in my case. they may be ugly and hard to work with at
times, but at least they fall to the ground and generally stay there.

enough rocks and one has a mound...

it stays there, but as a downside it is really heavy...

> Most dynamic languages are way too limited.
> I like to see ALL the bells and whistles of static approach,
> such as threading, async handling, event structure, performance,
> predictability of outcome, and things like that.
>

ok.

>> this is mostly since most VM's try to package everything into "one
>>size fits all" objects, and may end up with a big pile of different
>>classes
>>for every possible use case.
>
> Yep. I do not like that aspect of it.
> If you could construct that VM on the fly, depending on what exactly
> my app requires, that would probably make the whole thing leaner.
> Not sure how realistic the whole excersize is though.
>

yep.

it depends a lot on which parts are needed though, since there are annoying
dependency issues.
if all one needs is an assembler+linker or a GC, that is fairly easy...

if one wants (in my case), VFS, dynamic types, Class/Instance OO facilities,
... then they also end up needing to include the assembler and the GC.

the C compiler needs all of the above.
...

the x86 interpreter can operate standalone, but really likes to have the
former facilities (I ended up making it take the "back-roads" approach of
trying to load the DLLs and grab the interfaces, although I am generally
displeased with this strategy since it goes against my usual aesthetic...).

>>granted, generic facilities are often not as "nice" as in the "one size
>>fits
>>all" strategy (often, the more control that is given, the more internal
>>patchwork that is visible), and having to bring up subsystems by getting
>>and
>>setting lots of pointers isn't very nice, but it does have some merits.
>
> I could care less about what kind of magic you need to do
> while that thing is constructed at run time.
> As long as it buys me something at the end.
>

ok, fair enough.

I have some "pseudo-COM" stuff going on (if you have seen JNI, this is a
fairly good idea of what I am talking about). some parts are plugged
together with function-pointer structs, ...

>>>>the architecture should remain relatively open, as not to overly limit
>>>>possible use cases (consider if the VM is composed of lego blocks which
>>>>can
>>>>be put together in different ways under the discretion of the frontend
>>>>app);
>
>>> I'd LOVE to see THAT kind of thing.
>
>>well, it is an ideal at least.
>>the tangled bits and need to mess around with crap sometimes clouds the
>>vision.
>
> Just don't spread yourself too thin.
> I am not sure you have resources to handle so many different aspects.
>

hell, I don't think I have the resources either...
however, I hesitent of pruning anything either, so this is sort of a
dillema...

>>I guess it can be compared to trying to write an app making use of
>>DirectX.
>>luckily, much of this internal plumbing work is hidden in the details, but
>>at the cost that this (doing initialization automatically), itself,
>>creates
>>more internal dependencies and issues.
>
> Well, what do you expect if you are trying to reinvent the world?
> :--}
>

ok.

>>>>the VM should also play well with pre-existing technologies (I have
>>>>tried
>>>>to
>>>>base many of the components after fairly "standard" pieces, and although
>>>>imperfect at times, it is possible to use "off the shelf" apps for many
>>>>purposes, both to provide input or accept output);
>>>>....
>>>
>>>>so, I am at odds with both .NET and the JVM on philosophical grounds;
>>>
>>> I don't want to even HEAR about .net or asp.
>>> To me, that equates with profound evil, whose only purpose is
>>> to dominate the world. The same thing as NWO, only in sw business.
>>>
>>> That stuff is out the window for me, and for good.
>>> From my end, it is RADICAL non acceptance of the whole underlying
>>> philosophy of it, which is nothing more than maximization of the
>>> rate of sucking of the blood of many by the few.
>>>
>>> It is total NON portability.
>>> It is a police state equivalent of the "matrix", the sowtware industry
>>> version of it.
>>>
>>> It is a dead end that will NEVER, under ANY circumstances,
>>> will either solve any problems we are facing right now,
>>> or make things EASIER in order to make some genuine progress.
>>>
>>> It is nothing more than a giant speder web, whose square purpose
>>> is to catch as many flies and get them entangled in a deadly dance.
>>>
>>> It is UTTER NON cooperation. It is an idea of total control of destiny
>>> of human kind that eventually translates into a two class society,
>>> the "elite" and "slaves", and this is not just some "conspiracy
>>> theory". This IS the reality of what is going on.
>>>
>>> Those anti-globalists are not just some bunch of fools.
>>> I just learned recently that their leader happens to be a former
>>> supreme court justice. Someone who knows this thing so good, that
>>> many sculls are going to get cracked to even comprehend what he knows.
>>>
>>> Must be a person of total honesty to take SUCH a grand risk.
>>> He can be killed ANY moment and he knows that all too well.
>>>
>>> THESE are the kinds of people that need to be involved in politics,
>>> if we are to get any benefit for ALL, and not just fattest parasites,
>>> sucking every drop of blood they can find from the body of
>>> mankind.
>
>>ok.
>
>>>>and, I disagree with LLVM on architectural grounds (granted, I have a
>>>>mess
>>>>here, but personally I just don't really like LLVM's architecture);
>
>>> Sorry. Do not know what LLVM is.
>
>>LLVM is another VM, but which mostly sets itself up as a generic compiler
>>lower-end.
>
>>my main complaint is that the design is very centralized, and also that
>>the
>>whole thing is written in C++ and in a style I am not particularly fond
>>of.
>
>>may seem odd, but I believe the lower-end compiler machinery should be,
>>hopefully, decentralized and C-friendly (C++ can be used, but one should
>>not
>>expect any code which externally interfaces with it to do so by instancing
>>or extending classes, ...).
>
>>I am also not as fond of the single-class-per-file or manually including
>>"teh crapload" of class-specific headers, mostly because it means having
>>to
>>open and dig through far too many files to really follow the code.
>
> Well, Microsoft did not have that limitation, and I totally agree
> with that one. But it seems to be some kind of necessity overall.
>
> But what a royal pain it is. My main class source file is > 250k.
> Not that it is such a big deal with modern IDEs. But still, I'd
> prefer to see it split into smaller, logically related sections.
>

in the LLVM case, most of the headers and source files are too small...

so, maybe one opens a file to find it contains maybe 100 lines, 15-20 are
maybe header inclusions, and or a single class declaration, or maybe a few
methods. trying to follow the code is difficult as lots of time goes into
mostly opening and closing text editor windows...

I think it may be though a result of people using Eclipse as an IDE, and
Eclipse likes doing things this way?...

>>>>....
>
>>>>however, I have tried to minimize creating "novel" parts when possible.
>>>>
>>>>sadly, some level of "novelty" and "internal dependencies" are
>>>>inevitable
>>>>it
>>>>seems...
>
>>> Sure. There is no way around it. That's the whole trip of it at the end.
>
>>>>thus far, much of the VM revolves around "good old C", both as the
>>>>language
>>>>of implementation, and as the language of scripting. I have attempted to
>>>>move beyond C (Java and C# looked like good languages to try to add, and
>>>>JavaScript and Scheme also have some interest).
>
>>> C# - full stop.
>>> Red siren: WARNING: You are entering the domain of The Head,
>>> Microsoft, the Evil Most Profound.
>
>>> Unless C# is accepted by everybody and unless it is not a subject
>>> of copyrights and pattents, I would not touch it with a 6 foot poll.
>
>>> There is simply no need for it to begin with.
>
>>> C# does not solve anything so radical that is is worth even
>>> bothering with, regardless of how many language "experts" say
>>> it is salvation for mankind.
>
>>there is ECMA-334 and 335, which essentially mean that, as far as these
>>parts go, there is some level of openness. one can then implement which
>>parts are defined in these standards, and ignore most of the rest, and
>>technically MS is under their own legal obligations not to do anything
>>about
>>it.
>
> I just do not trust those guys ANY way you cut it.
> From what I've seen so far, these are just different kinds of traps,
> but you do eventually get trapped in that gook. And it is amazing,
> they did not realize how much they are hated by just about anyone
> for setting up all these traps and being totally closed, ignoring
> the rest of the world, like they are the only ones that have a final
> say on what is what.
>

yes, ok.

>>granted, you wont get the whole ".NET framework" this way, but one can get
>>C# and MSIL, which have a few merits.
>
> Well, I do not mind C# as such. I am looking at some things in passing,
> and yes, it does make SOME sense. I just fail to see what it boils down
> to at the end and what specifically does it buy me.
>
> I think people are too obscessed with compile time issues.
> For example, in Java generics, there is this type erasure thing,
> which means you loose your type during the run time.
> Well, I do not like the mechanisms like these in principle.
>

yes, ok.

>>the problem, however, is that both are fairly complicated in their full
>>form
>>(much more so than the JVM equivalents), and so would take a far higher
>>resource involvement to really implement effectively.
>
> I just do not see what does it buy me at the end.
>
> If your program is "incorrect", you can not be saved by compilers.
> Those are just small things that won't make your program "better".
> Because you prolly have holes in your architecture and design.
>
> People still write plenty of code in straigt C.
> For some strange reason, it is all over the place.
> And the more stable, more performing code, the more you get to the
> kernel level, the closer you tend to move toward C.
>

yes, it is odd.

I had liked it, since in theory it could offer a good tradeoff between C and
Java.
nevermind that it is big and complicated.

>>>>however, it is all a bit of a "trudging through mud" experience,
>
>>> And forever so.
>
>>>> and C
>>>>remains as the only really "usably complete" language in the mix
>
>>> Indeed. It is the ONLY true "revolution" in the software industry,
>>> that contributed more to it than all the other stuff combined.
>
>>yep.
>
>>>>(my C
>>>>compiler contains a few holes and failings, but for the most part it is
>>>>adequate).
>
>>> You mean you have your own C compiler? :--}
>>> That made my day!
>
>>yep.
>
> Wow!
> I am impressed.
>
>>it is mostly used for scripting.
>>for most other things though, I am using good old static C compilers (GCC
>>and MSVC), which do most of the "heavy lifting" as it were.
>
>>my compiler is binary compatible with the static compilers (so I don't
>>need
>>a FFI for C-based scripts).
>
>>>>but, ideally, an app will "use" a framework, rather than be "built on
>>>>top
>>>>of" it,
>
>>> What do you mean by that?
>
>>an app which uses something may continue to function without the object in
>>question, or may supply a substitute.
>
> Cool. You are pretty inventive I'd say.
> :--}
>

the usual strategy is to provide fallbacks.
something being missing causes it to use the fallback, which may be either a
simpler OS-provided facility, or if needed, a no-op facility.

this actually works fairly well in the majority of cases.
a lego by itself is still a lego, even if it doesn't necessarily do a whole
lot.

this is partly an "interesting" side effect of trying to keep code highly
modular, and plugging it together with interfaces:
in many cases, a component can be pulled or replaced, and other code will
often compensate automatically.

>>an app which is "built on top of" something, can't be reasonably expected
>>to
>>function without it.
>
>>for example, an app may use a GUI toolkit, or several of them, and then
>>some
>>way exists in which to "choose" which one to use (via build options, or
>>even
>>at runtime), or the app could provide a fallback (no GUI is available, so
>>it
>>falls back to a custom and more-simplistic interface, such as a
>>command-line, or simple custom-drawn widgets).
>
> You are really something else, I tellya.
> :--}
>

it is not that novel.

for example, many games will often do something similar, possibly trying
several different methods of getting the video and sound up and running
before ultimately giving up.

it can also be compared to how the OS uses drivers...

how flexible would an OS be if everything were hard-coded?...

so, usually most major components may have alternatives and fallbacks, and
most APIs can be designed as abstract interfaces where the machinery can be
replaced.

if OS kernels were written like how many apps were written, then the mess
which we would have would be horrible...

>>an app "built on top of" a GUI toolkit can't easily do this, and would
>>essentially need to be "ported" to the new toolkit, that or discarded and
>>rewritten.
>
> Yep, I do like an idea of dynamic wiring.
>

yep.

>>many toolkits and frameworks though are written to assume such a level of
>>dependency, and are problematic to try to use in such a way which does not
>>in some way significantly impact the app with which they are used, and
>>often
>>will not play well with another toolkit which does essentially the same
>>thing, since inevitably they will conflict over some or another "prized"
>>resource and would step on each other if one tried to use both.
>
>>>> and it "should" be a component which can be integrated into a
>>>>project (or dropped again) without otherwise requiring significant
>>>>modification.
>
>>>>this is the ideal, although granted, it is much work to achieve these
>>>>sorts
>>>>of ideals.
>
>>>>>>granted, nothing is perfect.
>
>>>>>>in general, I like C# though, as for the most part it seems a fairly
>>>>>>cleanly
>>>>>>designed language (apart from that it seems to need some level of
>>>>>>"black
>>>>>>magic" to be able to parse).
>
>>>>>>I am a little more hesitant about the rest of the .NET framework
>>>>>>though,
>>>>>>and
>>>>>>would rather it was something capable of being statically compiled and
>>>>>>operated standalone.
>
>>>>> I just looked at some of it in passing.
>>>>> Looks like some kind of equivalent of JVM underneeth.
>
>>>>C# is sort of like "Java's big brother" in terms of design. at its core,
>>>>they are in many ways fairly similar languages (just C# returns a little
>>>>closer to its C and C++ roots, re-adding many more features and
>>>>complexities...).
>
>>> Well, I saw some of that stuff. Never had enough time to get into
>>> it. And what I saw does not make that much of a sense to me.
>>> Just another pile of complications and bells and whistles
>>> that simply make my job MORE difficult and not less,
>>> even though they'd take me up on spears for saying things these,
>>> lil could I care though. Cause I know where I stand and what I need.
>>> Not them.
>
>>>>in a similar way, the .NET VM architecture is sort of like a "big
>>>>brother"
>>>>to the JVM.
>
>>> I bet it is a ripoff essentially.
>
>>historically, probably...
>
>>initially, MS implemented J# and their own customized (and MSified) JVM.
>>Sun did not take too keenly to their effort, and so there was a lawsuit.
>
>>shortly thereafter, MS made a new language: C#, which kept much in common
>>with Java (but added many syntax changes and new features).
>
> That is what I meant.
> I just saw too many Javaish things in C#, the whole MVM concept,
> and I bet the whole .net trip is the same thing.
> That is why I called them what I did.
>
> And I would not doubt in my mind that they intend to screw Sun
> at the end so they could suck in as many people into the webs
> they weave and Sun, for obvious reasons, barked at that.
> Not sure what I'd do in their place.
> But to take upon the microsoft, even if you get paid tons of bux
> at the end, was the end of Java, at least to vast majority of
> boxes out there. I think ms dropping java is probably the most
> monumental move in the entire history of sw industry.
>

yes, ok.

>>they also created MSIL / CIL, which shares many commonalities with JBC,
>>but
>>also differs in many ways as well.
>
>>>> there are many subtle aspects which are similar, but with one
>>>>notable and apparent difference:
>>>>..NET is FAR more complicated WRT its internal workings.
>
>>> Well, that IS the very core strategy of Microsoft.
>
>>> What it is is this: whenever you need to do ANY kind of improvement,
>>> do it in the MOST complicated way possible. So it takes those goats
>>> at least two years to feel comfortable with it.
>
>>> If you need to add 2 and 2, do it in such a way, that you have five
>>> layers of abstraction. Plug in universal-trans-gallactic,
>>> super duper omnipotent wrapper that won't even run unless they
>>> sign YOUR "protocols". Then document it as little as you can.
>>> And release it under the slogan of "New Revolutionary Technology"
>>> (of suckology).
>
>>yeah, a lot is just hacks and extensions of prior technologies.
>
>>MZ/EXE (from MS-DOS) and COFF (from Unix) were hacked together to produce
>>PE/COFF (used in 32-bit EXE's from Win95 and NT4 onwards).
>
> Its a pitty that people who initially concieved and designed these
> things did not even get a penny out of it.
>
> It was all repackaged and stamped with "copyright" or "patent" stamp.
> Simply disgusting.
>
> I did have some direct experience with MS a while back.
> What they asked me essentially is this: you give us your product
> for FREE and we will include it in OUR package, the O/S.
> And we won't pay you a penny in return.
> But you do get to be "approved" by us and we will get more money
> as a result of including more and more blood from the people and
> companies like you.
>
> I said: screw you and screw your whole trip. No deal.
>
> Those suckers did not even offer a PENNY.
> What a disgusting bunch of sickos, sucking blood from everyone
> they can get their hands upon.
>

yes, ok.

well, I think some amount of the Windows NT line was based on grabbing up a
bunch of source from BSD.

I found it mildly ammusing to have been looking at one of their SDKs, and
noting a copy of both the zlib and libjpeg liscense agreements...

>>then a bunch more crap was hacked on to create MSIL Images, which are
>>basically PE/COFF with a bunch of relational tables and stuff added, and
>>MSIL bytecode thrown in.
>
>>I also ended up using PE/COFF, mostly for compatibility reasons, but most
>>of
>>my metadata notably differs (my metadata is not based on a relational
>>structure, but is instead a heirarchical DB, mixed with some other parts
>>which are based on a TLV structure loosely similar to RIFF or PNG,
>>although
>>by default a bit more compact...).
>
> About the pittiest thing in this whole thing is that people
> like Gary Kildall simply get slaughtered at the end, while these
> parasites make a killing on the work of others.
>

well, CP/M was ripped off to make MS-DOS, and DOS was extended with a MacOS
immitation to make Windows 3.x, and was fused with DOS to make Windows 95.

elsewhere, the BSD codebase was grabbed up and largely reworked into NT,
some parts of which were common with Win95.

MS-DOS MZ-EXE header + BSD's COFF binaries became PE/COFF (replacing the
Win3x NE format, which was partly a horridly hacked DOS EXE I think with an
alternate entry point for Win16 code, and also LE which had been used I
think for Win32s and early Win95, ...).
...

well, no one ever really said they had to be original...

"embrace and extend", as the story goes, as one "rides on the shoulders of
giants"...

>>> The square purpose of Microsoft is to get everyone entangled into
>>> this gook, and once they are caught, there is no way out.
>>> Then attach your sucking tubes to their body and suck as much blood
>>> as you can manage. Until they can barely breath and walk.
>
>>> That IS the very core of their "strategy".
>
>>> The same thing is Google, the manifistation of evil even more
>>> profound from what I know.
>
>>> Recently I have heard that they have all these zombies running
>>> arount the hallways at Microsoft with plastic smiles, stuck on
>>> their faces, while thinking about ANY kind of crap they can
>>> come up with so it could be "patented".
>
>>> What Microsoft and Google do right now is to try to patent
>>> ANYTHING they can imagine. They pay people a few hundred bux
>>> if they come up with ANY crazy thing that could be patented.
>>> Not that they have ANY plans to actually use thesse "invention".
>>> But just to prevent ANYBODY from possibly doing it, and if they
>>> DO intent to use it and if they DO invent something, you can
>>> claim: sorry, you can only do it if I attach my sucking tubes
>>> to your body and suck your blood.
>
>>> The same thing is what Google is doing this very moment.
>
>>> The consequences are simply horrendous. I just thought about
>>> a couple of things and I had goose bumps, just to see what
>>> could be result of it in my specific situation, even though
>>> I don't think their zombies already patented some stuff I've
>>> been doing.
>
>>ok.
>
>>>>(the JVM has a few hairy bits, but in general it is "not that bad", and
>>>>a
>>>>beating together a working basic implementation is a "reasonably" easily
>>>>achievable goal).
>
>>> Well, good.
>>> That is ALL that counts at the end.
>
>>>> well, apart from the persisting lack of a class library
>>>>(writing Java code in a vacuum is not nearly so compelling).
>
>>> Well, I even heard some people in Java world complaining that
>>> Java has just WAY to much stuff, which should not belong to
>>> a language.
>
>>> From what I see, this C# stuff is mostly a ripoff of Java.
>>> But that is another matter.
>
>>> Just look at collections. They are rich enough to fill vast
>>> majority of applications and their performance is as good as
>>> it gets. All the algorithms that I saw are top notch
>>> implementations that approach the theoretical limit of a given
>>> approach.
>
>>> And that is ALL I want to hear about collections.
>>> And if you don't have something that is covered by collections,
>>> well, that is what programmers are for. Keeps you gainfully
>>> employed after all.
>
>>> In other words, I can not agree with this one.
>>> I'd like to see more substance to this argument.
>
>>as-is, I don't even really have "java.lang" in place, and so most of what
>>goes on would require plugging into C land
>
> Coolio! :--}
>
>>(and at the moment, likely
>>writing far more JNI code than actual Java).
>>similarly, it looks like a hassle to plug classpath into my project, as I
>>would have to write a lot of machinery to glue it.
>
>>possibly, I could try to go and write some wrappers for some of my C based
>>APIs, and then build some of the core Java API's on top of these.
>
>>so far, I have not done much of the sort.
>
>>>>> A single fact that you need to agree with something to even
>>>>> have your app to run under it, is a total no go for me.
>
>>>>> You can not even deliver your J# app as a single executable
>>>>> is simply berzerk. And now, you can not even compile Java
>>>>> starting with VC 2008 and higher. Disaster.
>
>>>>yeah.
>
>>>>>>little in the language particularly prohibits this, only that I am not
>>>>>>aware
>>>>>>of any standalone C# implementation.
>
>>>>>>it is, at the moment, a little easier to write standalone Java, since
>>>>>>there
>>>>>>is both GCJ, and JBC is simple enough as to make it not particularly
>>>>>>difficult to trans-compile to C or ASM
>
>>>>> Oh, interesting. Is there a way to generate Java code out
>>>>> of C++/MFC by any chance?
>
>>>>"there be dragons there".
>
>>>>Java can be compiled to C without too much horror,
>
>>> Well, I am talking about MFC specifically, and that is GUI
>>> stuff to a large extent, that works totally different than Java way.
>>> I don't think it is a trivial task.
>
>>yeah, probably a real horror that.
>
>>>> since for the most part
>>>>JBC uses a clear subset of C's basic capabilities (although, the
>>>>translation
>>>>is at a fairly low level of abstraction, for example, I operate
>>>>"underneath"
>>>>the JVM's stack model, and essentially remap stack operations to local
>>>>variables via a kind of naive graph-conversion algo...).
>
>>> Cool stuff. Why don't you publish more about it?
>>> Some principles, architecture or what have you.
>>> If you think you can do it or even interested in doing it...
>
>>it is fairly generic compiler stuff here.
>>a JIT is likely to be faced with many of the same issues.
>
>>just, translating stack operations into variable operations is a little
>>cheaper than faking the stack, and with JBC's restrictions, does not add
>>notably to the complexity.
>
>>a few of the ugly edge cases are mostly that there are a few opcodes which
>>assume a stack composed of 32-bit items and make some assumptions WRT item
>>size, which, errm, kind of turn ugly when dealing with an abstract stack.
>
>>>>I actually use a plain Java compiler to produce the class files, so that
>>>>I
>>>>could them mostly focus on translating the bytecode to C.
>
>>>>however, C does not map nicely to the JVM (even in the simple case, it
>>>>is
>>>>horridly inefficient, and even more horridly crappy), this much is not
>>>>likely worth the bother.
>
>>>>C++ -> Java, if possible, would likely be something too terrible to be
>>>>described.
>
>>> Too bad. Well, what to do? I was just trying to see if I could
>>> save a couple of months of work if I had not rewrite it by hand.
>>> But that's ok. We can live with that.
>
>>> I would REALLY like to port my monitoring firewall to linux.
>>> The problems are mostly GUI and low level network driver interface.
>
>>ok.
>
>>>>x86 -> Java or JBC should be possible, but I doubt would be of much
>>>>practical use (likely poor efficiency, and the languages would not be
>>>>able
>>>>to really relate or share data at a meaningful level). likewise for just
>>>>writing an x86 interpreter.
>
>>> Well, I did not expect to have much luck. But just in case.
>>> The stuff does not map from MFC to Java that well.
>>> Basically, you have to rewrite the whole thing.
>>> But I bet it is going to be the easiest thing in the world,
>>> going from C++/MFC to Java. It would probably be 3 times as hard
>>> to go the other way around. MFC sucks pretty bad as far as sophisticated
>>> GUI goes where you do not use the modal dialogs and where you dialogs
>>> are not some dumb, single threaded, fixed size miniscule boxes,
>>> just like about anything microsoft does, but are fully resizable,
>>> multi-threaded, property sheet/page dialogs.
>
>>> That thing would be a disaster to implement in MFC.
>
> I know. I am still struggling with some totally ridiculous stuff,
> just trying to resize some nested GUI stuff. The stupidest thing
> in the world and the amount of time I had to waste on it is just
> monumental compared to the functionality I was after. That same
> thing is a sneeze doing it in java and using nothing more than
> gridbag layouts.
>

yes, ok.

>>never really used MFC, though had used GDI+ some in the past.
>>mostly I use OpenGL and do my own widget drawing via GL, although there
>>are
>>drawbacks.
>
> Well, I used it from the day one. Basically, it is just an object
> oriented C++ wrapper for win32. So, I started using it as my main thing.
> Never regretted it, except when you have some nasty details
> and primarily in the GUI end of it, if you are writing some
> flexible GUI code.
>

yeah.

I mostly used GL since I do a lot of 3D stuff...
apparently, this is the same kind of thing as most 3D modeling packages, ...

>>>>however, an interpreter would allow, potentially, compiling C++ code to
>>>>x86,
>>>>loading the x86 in an interpreter and running it (at likely crap
>>>>speeds),
>
>>> No. Interpreters are totally out of the window for this job.
>
> I mean the firewall app.
>

'k.

>>> It is high traffic, high performance situation, where you have
>>> to do all sorts of tricks to make sure you are not blown out
>>> in some situations.
>
>>ok.
>
>>>>....
>
>>>>is it worthwhile?... probably not.
>
>>>>it is worth noting that low-abstraction machine-code like
>>>>representations
>>>>(including JBC and x86 machine code) are generally easier to translate
>>>>and
>>>>manipulate effectively, whereas with higher-level forms (such as source
>>>>code), one can generally do a much better job and has far more "power".
>>
>>> I don't know what is JBC.
>
>>Java ByteCode.
>
> Oh, Jeez!
> :--}
>
> Thats about the last thing I would even think about it.
> I thought it is some kind of gadget.
>

yes, ok.

>>>>however, JBC can be fairly faithfully converted to C (much easier than
>>>>many
>>>>other possible paths), and does not tend to introduce all that many
>>>>"impedence" problems.
>
>>>>hence, it works acceptably to convert Java to C by first compiling to
>>>>JBC
>>>>(AKA: class files), and then translating.
>
>>> I need C++, and specifically, MFC to Java.
>
>>ok.
>
>>can't much help here...
>
>>compiling code is a much simpler task than converting between API's...
>
>>>>however, this does not extend to the general case, and is very specific
>>>>to
>>>>various internal properties of both Java and JBC.
>
>>>>(although, granted, there are still a few sharp edges, but these are
>>>>managable).
>
>>>>for example, Java requires that the stack have exactly the same layout
>>>>at
>>>>both the source and destination of a jump, and that the layout of the
>>>>stack
>>>>is required to be constant at a given bytecode position.
>
>>>>the implications of these simple restrictions are notable and drastic,
>>>>and
>>>>without these particular rules, doing an effective translation would
>>>>have
>>>>been a much uglier problem (essentially requiring "simulation", rather
>>>>than
>>>>a value-flow graph-based translation, ...).
>
>>>>just imaging here that every push and pop pushes or pops an abstract
>>>>variable, rather than a value, and so the sequence of stack-based
>>>>operations
>>>>can be compared to putting down and picking up the ends of tubes and
>>>>plugging them into operations, and then putting down the result-tube,
>>>>...
>
>>>>the process, though naive, is elegantly simple, and can convert a method
>>>>from a sequence of stack operations, into a graph of interconnected
>>>>operations, which can then be (fairly straightforwardly) converted back
>>>>into
>>>>C code.
>
>>>>none of this holds with either C, C++, or x86 machine code, OTOH, and
>>>>hence
>>>>such a conversion is not directly possible as such.
>
>>>>or such...
>
>>> Hey. Good article. I really enjoyed it.
>
>>ok.
>
> What can I say, it is a pitty, society does not support the guys
> like you and give them some basic funding just to be able to exist.
> Because I think people like you can contribute more to the whole
> equation, that most of the big mouths out there, called "experts".
>
> Good luck.
>

yes, ok.

> --
> Programmer's Goldmine collections:
>
> http://preciseinfo.org
>
> Tens of thousands of code examples and expert discussions on
> C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
> organized by major topics of language, tools, methods, techniques.
>

==============================================================================
TOPIC: Design patterns
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
==============================================================================

== 1 of 7 ==
Date: Sat, Dec 26 2009 6:43 pm
From: tanix@mongo.net (tanix)

In article <70900cf2-609c-45cc-869a-405471aff554@j14g2000yqm.googlegroups.com>, MiB <michael.boehnisch@gmail.com> wrote:
>Selecting design pattern(s) for an application is a delicate process.
>On a more macroscopic level, it requires in-depth analysis similar to
>selecting an algorithm for solving a problem.
>
>In order to make an educated choice, in both cases you need to know a
>number of alternatives, i.e. strong points and drawbacks of design
>patterns for the task at hand as well as you need this for algorithms.
>I did not check the web site you gave, but I assume its a kind of
>collection or catalog of design patterns - of course it is not a good
>idea to stick in design patterns into writing an application
>indiscriminately but a catalog is a good knowledge base for not having
>to invent the wheel over and over again.

Well, I am not against the design patterns in principle.

But what I DO see all over the place is a literal obscession.
That web page used two design patterns for a single thing.
I do not argue whether it IS the way to go or not.

But that looked like an extremism to me, just from glancing at it.

>best,

> MiB

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

== 2 of 7 ==
Date: Sat, Dec 26 2009 6:45 pm
From: tanix@mongo.net (tanix)

In article <ccd94e2c-0bfa-49eb-9f25-45f1a96854f7@e37g2000yqn.googlegroups.com>, James Kanze <james.kanze@gmail.com> wrote:
>On Dec 26, 3:07 pm, ta...@mongo.net (tanix) wrote:
>> I just read one article here about patterns and it made me
>> shiver.
>
>> Are you guys trying to find a solution to your issue by first
>> looking if you can find as many "design patterns" as you can
>> find and then try to stick as many of them into your code, as
>> you can manage?
>
>Maybe some are, but I've not encountered any. I have
>encountered a lot of programmers who prefer reinventing known
>solutions rather than using existing ones. In the end, using
>design patterns is just using a common language for talking
>about existing solutions, so you don't have to reinvent known
>solutions each time around. (The common vocabulary is extremely
>useful for documentation purposes.)
>
>> Is THAT the central idea about modern programming techniques?
>
>The central idea about modern programming techniques is to
>produce error free, maintainable software as cheaply as
>possible. Using known solutions, when applicable, is an
>effective technique for that.

Thanx God!
I started feeling I am in a dreamland.
:--}

>--
>James Kanze

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

== 3 of 7 ==
Date: Sat, Dec 26 2009 6:47 pm
From: tanix@mongo.net (tanix)

In article <741bd777-b2ba-46be-8720-184ab692e091@j42g2000yqd.googlegroups.com>, Jonathan Lee <chorus@shaw.ca> wrote:
>On Dec 26, 10:07=A0am, ta...@mongo.net (tanix) wrote:
>> Are you guys trying to find a solution to your issue
>> by first looking if you can find as many "design patterns" as you
>> can find and then try to stick as many of them into your code,
>> as you can manage?
>>
>> Is THAT the central idea about modern programming techniques?

>Absolutely.

Well, what was what I was afraid of to tell you the truth.

> In fact, for my undergrad thesis I'm working on a
>"problem description language" that will take your problem/goal
>and re-express it in design patterns. It will then write the
>program by mechanically applying the design patterns.
>
>But I'm having a small problem finishing it. Anyone know of a
>pattern for the above problem?

:--}

Well, unfortunatly I do not have a reference to the article
by that French professor and I am not sure it is going to be
as encouraging for your trip, as you might expect otherwise.

>--Jonathan

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

== 4 of 7 ==
Date: Sat, Dec 26 2009 6:51 pm
From: tanix@mongo.net (tanix)

In article <GPS-20091226203722@ram.dialup.fu-berlin.de>, ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>Jonathan Lee <chorus@shaw.ca> writes:
>>But I'm having a small problem finishing it. Anyone know of a
>>pattern for the above problem?
>
> Sure, just implement it as a GPS.
>
>http://en.wikipedia.org/wiki/General_Problem_Solver

I like this one:

"While GPS solved simple problems such as the Towers of Hanoi that could be
sufficiently formalized, it could not solve any real-world problems because
search was easily lost in the combinatorial explosion of intermediate states."

And that is EXACTLY what that French professor said
about 20 years ago if I recall correctly.
:--}

"combinatorial EXPLOSION".
Nothing less.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

== 5 of 7 ==
Date: Sat, Dec 26 2009 7:14 pm
From: tanix@mongo.net (tanix)

In article <hh5q24$vpm$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>Stefan Ram wrote:
>> Jonathan Lee <chorus@shaw.ca> writes:
>>> But I'm having a small problem finishing it. Anyone know of a
>>> pattern for the above problem?
>>
>> Sure, just implement it as a GPS.
>>
>> http://en.wikipedia.org/wiki/General_Problem_Solver
>>
>Hm, back in 1987. my math teacher showed us mathematical proof that
>algorithm for creating algorithms can;t possibly exist.

Yep.

>It is based on proof that algorithm for proofs can;t possibly exits
>, too...
>http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
>That's why blue brain project is bound to fail.
>Because anything which is based on algorithm cannot
>be creative...

Correct.

>Greets

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

== 6 of 7 ==
Date: Sat, Dec 26 2009 7:19 pm
From: tanix@mongo.net (tanix)

In article <7270e89a-093a-4c9a-846d-6f3d171d3730@c34g2000yqn.googlegroups.com>, Joshua Maurice <joshuamaurice@gmail.com> wrote:
>On Dec 26, 3:01=A0pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>> Stefan Ram wrote:
>> > Jonathan Lee <cho...@shaw.ca> writes:
>> >> But I'm having a small problem finishing it. Anyone know of a
>> >> pattern for the above problem?
>>
>> > =A0 Sure, just implement it as a GPS.
>>
>> >http://en.wikipedia.org/wiki/General_Problem_Solver
>>
>> Hm, back in 1987. my math teacher showed us mathematical proof that
>> algorithm for creating algorithms can;t possibly exist.
>> It is based on proof that algorithm for proofs can;t possibly exits
>> , too...http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theore=
>ms
>> That's why blue brain project is bound to fail.
>> Because anything which is based on algorithm cannot
>> be creative...
>
>Interesting implications there. Almost brings a religious context to
>the whole discussion. (That is, are humans "simple" chemical machines,
>or do we possess a "soul"?) Suffice to say, you are greatly
>simplifying the issues involved and jumping the gun.
>
>This is already so off-topic, but I suggest reading some good books on
>evolution by natural selection. Dawkin's The Greatest Show On Earth
>does a remarkably good job describing evolution by natural selection,
>specifically how evolution by natural selection may be the only known
>natural process which creates information in a local open system, the
>only process which creates information which is not intelligent
>design. "The non-random survival of randomly varying replicators."
>
>Throw on a couple good books of information theory and entropy for
>good measure.

How bout this one:

"There are no closed systems. So the issue of entropy does not apply".

>On the flip side, who ever proved that humans are "creative"? Or any
>moreso than a really good computer AI (which has not yet been made)?

AI is just a myth.
How can you possibly create an ARTIFICIAN intelligence
if you don't even know how natural, and that is biological,
intelligence "works"?

AI is simply trying to copycat that, which alredy exists
in biological world.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

== 7 of 7 ==
Date: Sat, Dec 26 2009 8:57 pm
From: Jonathan Lee

On Dec 26, 9:47 pm, ta...@mongo.net (tanix) wrote:
> >But I'm having a small problem finishing it. Anyone know of a
> >pattern for the above problem?
>
> :--}
>
> Well, unfortunatly I do not have a reference to the article
> by that French professor and I am not sure it is going to be
> as encouraging for your trip, as you might expect otherwise.

It's OK; I have a design pattern for changing my expectations.

--Jonathan

==============================================================================
TOPIC: Interfacing C++ and assembler code
http://groups.google.com/group/comp.lang.c++/t/79272d2bf39c62ec?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 26 2009 7:18 pm
From: "BGB / cr88192"

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:6b7e7992-2234-4209-b2aa-07916aaa8e41@upsg2000gro.googlegroups.com...
> Hi all.
>
> When one mixes C++ and assmbler code one needs to
> know a few details about the way the CPU works. In particular,
> one would need to know
>
> 1) what registers and variables must be left alone
> 2) which variables and registers might be manipulated
> inside the routine if the contents are restored before
> the routine terminates
> 3) what registers and variables one is free to play with at will.
>
> Where can one find information about such details?
> I am particularly interested in stuff relating to VS2008.
>

http://en.wikipedia.org/wiki/Calling_convention

and:
http://en.wikipedia.org/wiki/X86_calling_conventions

these give a general overview and provides a few useful links.

for example:
http://www.agner.org/optimize/calling_conventions.pdf

however, if you are intending to mix C++ and ASM, it is suggested to use the
'extern "C"' modifier for both imported and exported code, as this makes the
job a lot easier.

extern "C" {
void foo() //foo does not use name mangling
{
...
}
};

void bar() //but bar may be name-mangled
{
...
}

particularly of note is 'cdecl' (Win32) and the Win64 calling convention.

if 'extern "C"' is not used, then one has to deal with the C++ ABI, which is
generally compiler specific, and also more complicated (may involve name
mangling, additional "hidden" parameters, concern over things like object
and vtable layout, ... which can be generally avoided by pretending all is
C...).

> Rune

==============================================================================
TOPIC: ===Welcome to comp.lang.c++! Read this first.
http://groups.google.com/group/comp.lang.c++/t/eaae59a3ac3d0782?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 26 2009 9:30 pm
From: Shiva

Welcome to comp.lang.c++! Read this first.

This post is intended to give the new reader an introduction to reading
and posting in this newsgroup. We respectfully request that you read
all the way through this post, as it helps make for a more pleasant
and useful group for everyone.

First of all, please keep in mind that comp.lang.c++ is a group for discussion
of general issues of the C++ programming language, as defined by the ANSI/ISO
language standard. If you have a problem that is specific to a particular system
or compiler, you are much more likely to get complete and accurate answers in a
group that specializes in your platform. A listing of some newsgroups is given
at the end of this post.

The FAQ (Frequently Asked Question) list has a wealth of information for
both the new and veteran C++ programmer. No matter what your experience
level, you are encouraged to read the entire list, if only to familiarize
yourself with what answers are available to minimize redundant replies.
The comp.lang.c++ FAQ is available at http://www.parashift.com/c++-faq-lite/

If the FAQ list does not help, then many regular readers of this group
are happy to assist with problems of standard C++. We have only a few
requests that we ask be adhered to, for the benefit of all:

* Please put a short summary in the subject line. Descriptions such as
"HELP!!!!!!" are not helpful, and many regular posters ignore such
requests. A good example is, "Problem with Virtual Functions."

* State the question or the problem clearly and concisely. Describe what
you are trying to do, and the problem you are running into. Include all
relevant error messages.

* Include the smallest, complete and compilable program that exhibits your
problem. As a rule, posters in comp.lang.c++ will not do homework, but will
give helpful hints if you have shown some willingness to try a solution.

* comp.lang.c++ is forum for discussion, and as such some regular posters do
not give E-mail replies. Very often follow-ups to postings have corrections,
so plan on taking part in the discussion if you post a question. If you
do receive e-mail replies, it is considered polite to post a summary.

* Don't post in HTML format. Many readers of this newsgroup don't use
newsreaders which can handle HTML postings.

* If you have to include source code in your post, include the
source in the message body. Don't use attachments. A lot
of contributors to this newsgroup won't even notice the existence
of attachments or won't open them. You try to get any help
you can get, don't you?

Some netiquette topics which frequently crop up on comp.lang.c++ are
also answered in the FAQ.

* Should I post job advertisements and/or resumes on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10

* What if I really need a job; should I post my resume on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.11

* What should I do to someone who posts something off-topic?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12

A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.

This is a very busy group, so these requests are designed to make it as
pleasant and efficient an experience as possible. We hope it proves
a valuable commodity to you.

A list of some Newsgroups :
Languages and Programming
-------------------------
comp.lang.c The C Programming Language
comp.lang.asm.x86 x86 assembly language programming
comp.programming Non-language specific programming
comp.graphics.algorithms Issues of computer graphics

Operating Systems
-----------------
comp.os.msdos.programmer DOS, BIOS, Memory Models, interrupts,
screen handling, hardware
comp.os.ms-windows.programmer.win32 MS/Windows: Mice, DLLs, hardware
comp.os.os2.programmer.misc OS/2 Programming
comp.sys.mac.programmer.misc Macintosh Programming
comp.unix.programmer General Unix: processes, pipes, POSIX,
curses, sockets
comp.unix.[vendor] Various Unix vendors

Microsoft VC++
-------------
microsoft.public.vc.language VC++ issues
microsoft.public.vc.mfc MFC Issues
microsoft.public.dotnet.languages.vc C++/CLR Issues
microsoft.public.dotnet.framework .Net Framework

Borland C++ Builder
-------------------
borland.public.cppbuilder.language Borland C++ Builder
borland.public.cpp.language
borland.public.cppbuilder

-Shiva
http://www.slack.net/~shiva/welcome.txt

Sun Dec 27 00:30:01 EST 2009

==============================================================================
TOPIC: Gigantic Class
http://groups.google.com/group/comp.lang.c++/t/b3756783d92fd56a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 26 2009 9:53 pm
From: Immortal Nephi

I consider to use either object-based programming or object-oriental
programming. I am not sure to choose the correct programming
paradigms. I start with object-based programming because I need
encapsulation.
I provide client the interface. The client uses it to define object
in main() function body. They invoke object's public member
functions. The object's public member functions do the job to process
algorithm. All private member functions and implementation details
are hidden.
The base class is growing too big because I add more private member
functions. I debug and test them to be working properly. They are
less reusability. You will say that gigantic class is bad practice.
Why do you think that gigantic class is truly necessary?
I get quote from The ANSI / ISO C++ Professional Programmer's
Handbook.

Gigantic class

There are no standardized methods for measuring the size of a class.
However, many small specialized classes are preferred to a bulky
single class that contains hundreds of member functions and data
members. But bulky classes do get written. Class std::string has a
fat interface of more than 100 member functions; clearly this is an
exception to the rule and, to be honest, many people consider this to
be a compromise between conflicting design approaches. Still,
ordinary programs rarely use all these members. More than once, I've
seen programmers extending a class with additional member functions
and data members instead of using more plausible object-oriental
techniques such as subclassing. As a rule, a class that extends a
20-30 member function count is suspicious.
Gigantic classes are problematic for at least three reasons: users of
such classes rarely know how to use them properly, the implementation
and interface of such classes tend to undergo extensive changes and
bug-fixes; and they are not good candidates for reuse because the fat
interface and intricate implementation details can fit rarely only a
very limited usage. In a sense, large classes are very similar to
large functions.—they are noncohesive and difficult to maintain.

[end of quote]

How do you solve to divide into hundreds of subclasses from one giant
class? Inheritance is the answer, but you write derive class to use
**some** or **all** inherited member functions. You don't want client
to use all inherited member functions. They only need to derive class
through private inheritance.

For example:

class A
{
public:
A() : a( 1 ), b( 2 ) {}
~A() {}

protected:
int a;
int b;
};

class B : public A
{
public:
B() : c( 3 ), d( 4 ) {}
~B() {}

protected:
int c;
int d;
};

class C : public B
{
public:
C() : e( 5 ), f( 6 ) {}
~C() {}

protected:
int e;
int f;
};

class D : private C
{
public:
D() : g( 7 ), h( 8 ) {}
~D() {}
void Run()
{
a += 100;
b += 200;
c += 300;
d += 400;
e += 500;
f += 600;
g += 700;
h += 800;
}

protected:
int g;
int h;
};

class E : public D
{
public:
E() : i( 9 ), j( 10 ) {}
~E() {}
void Run()
{
D::Run();
i = 900;
j = 1000;
}

private:
int i;
int j;
};

int main()
{
E e; // object e is the interface
e.Run(); // Run() is available to client.
Return 0;
}

Do you see private inheritance? All data members and member
functions are inherited down to class C and all of them are
inaccessible in class D. All data members and member functions are
inherited down to class E from class D.
The client can use only class D's data members and member functions
that are already inherited in class E.
My example above is object-based programming. All data members and
member functions are grouped in only one big class through
inheritance.
What if you are going to say? Use object-oriental programming
instead? Base class is the general and all derived classes are
specialized.
For example, base class is the CPU's **ALL** instruction sets. It
has internal registers as data members and pure virtual member
function Dispatch(). Each derived class have specialized instruction
sets and Dispatch() implementation.
Why should each derived class be instanstized and data members are
inherited from base class? You only need one instance like I
described that giant class has one instance.

==============================================================================
TOPIC: "Reusable" operator overloading for enum?
http://groups.google.com/group/comp.lang.c++/t/981ab2c7a0c2c5ff?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Dec 26 2009 10:36 pm
From: nick

I'm sort of rusty at C++, so this may be silly, but here's my
situation:

I have an enum like this:

enum ParserMode
{
PM_NONE = 0,
PM_READY = 1, // ready for next col or row, or EOF
PM_EMPTY = 2, // empty cell
PM_CELL = 4, // cell
PM_QCELL = 8, // quoted cell
PM_HEAD = 16, // header cell
};

And elsewhere I want to write something like:

void DoStuff(ParserMode m)
{
if (m & PM_HEAD)
...
else if (m & PM_QCELL)
...
}
...
DoStuff(PM_CELL | PM_EMPTY | PM_HEAD);

But this will not work, because the compiler complains about not being
able to cast between int and ParserMode. So some operator overloading
clears that up:

inline ParserMode operator|(ParserMode p1, ParserMode p2)
{
return (ParserMode)((int)p1 | (int)p2);
};
inline ParserMode operator&(ParserMode p1, ParserMode p2)
{
return (ParserMode)((int)p1 & (int)p2);
};
inline ParserMode operator~(ParserMode p1)
{
return (ParserMode)(~(int)p1);
};
inline ParserMode& operator&=(ParserMode& p1, ParserMode p2) {
p1 = p1 & p2;
return p1;
}
...

...And everything works fine. But, now I need to add another enum, and
I don't want to copy all of these overloaded operators for this other
enum. Is there some way I can share one set of operator overloads
between many enums using templates, macros, or some other trick, or am
I just going about this wrong altogether?

Thanks in advance for any help.

-- Nick

==============================================================================
TOPIC: Cheap Nike Air Jordan Shoes Wholesale free shipping (www.vipchinatrade.
com)
http://groups.google.com/group/comp.lang.c++/t/6d12422d1bdd2c81?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 27 2009 12:19 am
From: google

We offer Cheap Nike Shoes, Air Jordan Shoes are on sale now, our Air
Jordan shoes, Nike Shoes are exclusive and we offer original box of
jordan shoes.
Nike Air Jordan Shoes
Cheap Wholesale Jordan 1 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 1.5 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 2
Cheap Wholesale Jordan 2.5 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 3
Cheap Wholesale Jordan 3.5
Cheap Wholesale Jordan 4 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 4.5
Cheap Wholesale Jordan 5 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 5.5
Cheap Wholesale Jordan 6 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 6.5 Kid
Cheap Wholesale Jordan 7 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 7.5
Cheap Wholesale Jordan 8
Cheap Wholesale Jordan 9 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 9.5
Cheap Wholesale Jordan 10
Cheap Wholesale Jordan 11 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 11.5
Cheap Wholesale Jordan 12
Cheap Wholesale Jordan 12.5
Cheap Wholesale Jordan 13 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 14
Cheap Wholesale Jordan 15
Cheap Wholesale Jordan 15.5 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 16
Cheap Wholesale Jordan 17
Cheap Wholesale Jordan 18 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 19
Cheap Wholesale Jordan 19.5
Cheap Wholesale Jordan 22 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 22.5
Cheap Wholesale Jordan 23
Cheap Wholesale Jordan 24 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Air Yeezy
Cheap Wholesale Jodan 23+AF1
Cheap Wholesale Jordan 1+Jordan 2+Jordan 5+Jordan 7
Cheap Wholesale Jordan 3+AF1 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 3+Jordan 5+Jordan 15 (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Jordan 4+AF1
Cheap Wholesale Jordan 4.5+AF1
Cheap Wholesale Jordan 5+AF1 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 6+AF1 Cheap Wholesale Jordan 9+AF1
Cheap Wholesale Jordan 9+Jordan 23 (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Jordan 11+AF1
Cheap Wholesale Jordan 11.5+AF1
Cheap Wholesale Jordan 11+Anthony (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Jordan 11+Jordan 12
Cheap Wholesale Jordan 11+Jordan 13
Cheap Wholesale Jordan 11+Jordan 23 (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Jordan 11+Obama
Cheap Wholesale Jordan 12+AF1
Cheap Wholesale Jordan 13+AF1 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 13+AJ6Rings
Cheap Wholesale Jordan 16.5+AF1 (paypal payment)
(www.vipchinatrade.com )
Cheap Wholesale Jordan 18+Jordan 23
Cheap Wholesale Jordan 20+AF1 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 21+Jordan 23
Cheap Wholesale Jordan 25+AF1 (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan 6 unite1 Cheap Wholesale Jordan 8 unite1
Cheap Wholesale Jordan flying (paypal payment)(www.vipchinatrade.com )
Cheap Wholesale Jordan foamposite liite Man
Cheap Wholesale Jordan Melo M5
Cheap Wholesale Jordan True Flight
Cheap Wholesale Jordan Trunner Q4 (paypal payment)
(www.vipchinatrade.com )

==============================================================================
TOPIC: ♣Y(^o^)Y♣ 2009 Wholesale cheap Gucci shoes at www.ecyaya.com [paypal]
http://groups.google.com/group/comp.lang.c++/t/ccea7aca103c4911?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Dec 27 2009 12:21 am
From: hero

♣Y(^o^)Y♣ 2009 Wholesale cheap Gucci shoes at www.ecyaya.com [paypal]

Men size 40,41,42,43,44,45,46. Women size 36,37,38,39,40.
High quality wholesale Air Force One shoes, Nike Jordan, Nike,Air
Max,
Nike Shox, Puma Shoes, Nike shoes, Adidas Shoes, Christian Louboutin,
Chanel Shoes, Coach Shoes, D&G Shoes, Dior Shoes, ED Hardy Shoes,
Evisu Shoes, Fendi Shoes, AFF shoes, Bape shoes, Gucci Shoes, Hogan
shoes, Bikkembergs Shoes, Dsquared Shoes, LV Shoes, Timberland Shoes,
Boss shoes, Versace Shoes, Prada Shoes, Lacoste Shoes, Mauri Shoes,
DC
shoes ect. Details at website www.ecyaya.com.
Cheap wholesale shoes
www.ecyaya.com
Cheap wholesale Gucci shoes
http://www.ecyaya.com/category-582-b0-Gucci-Shoes.html
Cheap wholesale Gucci Boots
http://www.ecyaya.com/category-588-b0-GUCCI-Boots.html
Cheap wholesale Gucci Women High
http://www.ecyaya.com/category-587-b0-Gucci-Shoes-Women-High.html
Cheap wholesale Gucci Men High
http://www.ecyaya.com/category-586-b0-Gucci-Shoes-Man-High.html
Cheap wholesale Gucci Men shoes
http://www.ecyaya.com/category-583-b0-Gucci-Shoes-Man.html
Cheap wholesale Gucci Women shoes
http://www.ecyaya.com/category-584-b0-Gucci-Shoes-Women.html
Cheap wholesale more shoes at Website:
www.ecyaya.com

== 2 of 2 ==
Date: Sun, Dec 27 2009 12:21 am
From: hero

♣Y(^o^)Y♣ 2009 Wholesale cheap Gucci shoes at www.ecyaya.com [paypal]

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en

To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

soft and program

Sunday, December 27, 2009

comp.lang.c++ - 18 new messages in 10 topics - digest

No comments:

Blog Archive

About Me