Lei el link que mandaste. Me pareciera que no es nuestra postura (al menos hablo por mi) derribar ni ser un militante anti-reduccionista. El reduccionismo es una herramienta muuuy importante. Quizas lo que es mas interesante es observar los lugares donde el reduccionismo se queda corto.
Todos nosotros (creo) tenemos un background donde el reduccionismo es un lugar casi "natural". Para que no quede suelto en el aire y quede como que a nosotros solo nos gusta parlotear, especificamente en nuestro ambito, el reduccionismo es un lugar tipico y casi "natural".
A veces me pareciera que particionar la realidad, una y otra vez nos impide ver un panorama mas amplio. Nos "reducimos" nosotros. Tampoco se habla de no usar el reduccionismo, sino de tener cierto criterio. Poder entrar y salir de las partes. Hacer zoom y luego salir hacia arriba, indistintamente e intentar ver mas cabalmente como se articulan las cosas.
----- Original Message ----- From: "Imre v. Soos" <imre.soos@...> To: "Bertalanffy-list" <bertalanffy@...> Sent: Friday, January 09, 2009 1:48 PM Subject: [Bertalanffy] posting
Greetings All. I was delighted to hear that the Bertalanffy Discussion Forum was finally revived by Tom Mandel (hi Tom, it is nice to know that you are around), and that with a vital and fundamental question. After reading through all the correspondences, I am once more delighted to say that, this time, I am very much in agreement with him. Here are my thoughts on the subject:
"The comments so far are very interesting - as Tom wrote - but hardly form a consensus", because everybody appears to have a different concept behind the label. The reason for this are the various synonyms the word "system" has, like: scheme, organisation, arrangement, classification, structure, co-ordination, organism, method, technique, procedure, and even orderliness and logic. If all and everything these labels cover are being stuck under the label "system", than the answer is that all and everything is a system, and Tom wouldn't have popped the question.
The right approach would rest in Tom's further clarification: "What I had in mind when I asked the question was the integrative system, the kind where the elements work together and form from that a new whole. The question is important when we talk about integrative systems because the new whole is actually the emergent property of the relationships." Just as right is James Rose by stating that "GST addresses deeper principles and ideas - it challenges the methods of analysis themselves and how people think and assess what they encounter." - I will follow these lines of thoughts, because they coincide with my ideas.
Ever since the proton, neutron and electron - the three stable fundamental particles of all material manifestation - ceased to be "hard little balls" and became swirling energy-bundles of ordered processes in interwoven and interdependent harmonic system-relationships of energy-quantums; and the various intertwining and spinning processes of their harmonious interactions are forming the hundred or so stable elements; which, in turn, can constitute, according to their valency, innumerable chemical substances, stable molecules, "things" also ceased to be "things", and became harmonious, rational and productive "processes": dynamic systems of various orders of complexity.
The above chain of systems continues, in growing order of complexity, through macromolecules of aminoacids, organelles, cells, tissues, organs, germinal-organ-systems, organisms, ecological communities, planetary life-complex. Above the two directional linear interaction of the members of this chain, there exists also the perpendicular interaction of each member with those on its own level, rendering the planetary life-system to be a spatial concept.
I must stress the attribute "harmonious", because harmony is a fundamental factor in all constructive manifestation (as is "cacophony", its antagonistic opposite, a destructive, degenerative one); and is thus a foundation principle of the Universe. It produces monistic relationship - or inversely, monistic relationship represents harmony.
I must also stress the attribute "rational", because ad-hoc events cannot enter into and be parts of a harmonious relationship and cooperation.
And I must also stress "productive", as the necessary attribute of both the individual constituents, and of the new system of higher complexity they constitute.
Consequently, the concept 'system' - within the limits of the General System Research and Theory - should represent the harmonious, rational and productive interaction of constituting elements, forming, through these properties, a complete unit, that becomes thus more than the sum of its constituting elements, and that cannot be reduced to, or derived at through the analysis of any of its constituents.
The reducibility principle comes from what I must call a belief, that a system originates through the interaction of two or more material elements, and is the derivative of the qualities inherent in these constituting material elements, which themselves cause the interaction; and that, through their analysis, the whole system can be known and synthesised. In turn, this principle is based on the belief that the new system becomes, through the original interaction, just another "thing" but of higher complexity than are its constituting "things".
The "interaction" of the constituting elements does not represent the triggering off the "being" of a new system of higher complexity, but is a sine qua non constituent of the new system in form of its incessant process of "becoming", the cessation of which process would result in the immediate disintegration of the system into its constituting elements. Thus, the "interaction" itself is as much a constituting element of the derivative system, as are all the "material" ones, even if it is of non-material nature.
That the "interaction" itself is not of material nature, and that neither is it inherent in any of the constituting elements, I will illustrate with the simple example of water:
If a container is filled with a mixture of oxygen and hydrogen, the oxygen, being the heavier, will settle in the lower part, and the two gases will stay in that state side by side till doomsday, without ever changing their identity. Never will they turn themselves into water, or into hydrogen-hyperoxide, through an inherent, self-induced process. By introducing a spark or high pressure into this mixture, the consequent explosion will end up by joining two hydrogen and one oxygen atoms, to be held together by relatively strong (valence) forces, which compound, in consequence, will act as water molecules with completely different physical and chemical identity and distinctively new character, without any reference to that of any of its parts, which become unrecognisable in the new complex. This new "identity" manifests the underlying "mind-stuff", that transcends the constituting elements and is inherent in the derivative system.
At the first stratum of the Natural Order, where materialisations happen, where elementary matter (proton, neutron and electron) appear, formed out of electromagnetic energy-quantums by their particular ordering principles (the inferred, but unexplained 'virtual particles' of nuclear physics) into swirling energy-bundles of ordered processes (and where they can also disintegrate, leaving behind electromagnetic radiation), there exist only two constituents "interacting" to form the systems of elementary particles: free energy-quantums and their ordering principles that are not of material nature.
The further consideration that these ordered processes, consisting of energy and mind-stuff, are constituting the atoms of all the elements according to their particular ordering principles of the second order; and that a same kind of systematic procedure continues towards ever increasing complexities, brings to the conclusion, that free energy and differentiated underlying principle are the two common denominators of all the material manifestations; and that matter, in all its forms, is a structured process complex of by the mind ordered energy-fields at all levels of its manifestation, and that the Universe - as any part of it - is formed by order imposed over a primordial energy-soup by the Ordering Principle which pervades it. This idea, or rather knowledge, is expressed concisely by the Nobel laureate biologist George Wald of Harvard: "The stuff of the universe is mind stuff."
The planetary life-complex includes each and all of its constituents in systemic co-existence, from the elementary particles upwards. It is self-configuring and self-sustaining, being dependent only on the energy-source of the Sun.
For a system to function harmoniously, rationally and productively, its underlying principle, that animates the constituent parts into a system of higher complexity, must possess these qualities. I would go even further to state that a functional, natural system is alive at its own level of existence, due to its underlying mind-stuff being alive, conscious and intelligent at the level of its manifestation.
I suggest that from a universal point of view, an entity is alive if it partakes - at the level of its own being - as a subject, instrument and originator in the universal life-processes. Von Bertalanffy's and Woltereck's anamorphosis, i.e., tendency to create new forms of life; Schrödinger's feeding on negative entropy; Herrick's spontaneously developing states of greater heterogeneity and complexity; and Szent-Györgyi's syntropy, that is, innate drive in living matter to perfect itself, are clear manifestations of the will to live and the will to evolve.
Considering that, summarised: each system represents more than the sum of its parts; each system is constituted of systems of a lower order and its ordering principle; each system is an integral constituent of a system of a higher order; and that none of the systems can be reduced to any of its constituent parts; - a "system" is, in fact a holistic order, where the label "system" can be exchange with the label "holon" without altering anything on the general concept.
The Universe itself is a self-configuring system, where macrocosmic and microcosmic self-configurations are co-emergent and interdependent, and represent thus one self-evolving and self-maintaining system. While the evolution starts on the one extreme with the formation of elementary particles out of electromagnetic energy, the macrocosmic starts with the spatial distribution and ordering of these same elementary particles, developing the double helix by starting simultaneously from both extremes.
Thought, logic and creativity are as intrinsic in the microcosmic existence as in the macrocosmic one. Microcosmic logic and creativity is producing and is constantly juggling and reshuffling all the fundamental and ephemeral subatomic particles, without ever leaving any of it to chance, providing dependable building blocks, basic rules and ordered energy supplies for a universe with infinite varieties of form and action. Macrocosmic logic and creativity maintains and recreates space-time - the thought-form defining inertial behaviour of matter -, every instant altering its curvature according to the momentary state of distribution of matter in the universe; and keeps on manifesting itself in solar and galactic development, dynamic equilibrium and self-generated and self-sustained metabolic processes, as those of the whole universe. Within all the ordered turbulence, energy, coalesces into forms of inorganic and organic matter, composing the biological structure of living organisms able to support various levels of higher intelligences, and constituting the crystalline structure of their underlying ground. This particular reference frame is at the level of the greatest complexity and diversity within a universal system. It is the centre of the evolutionary double helix spiralling from the two infinite extremes: the point towards which syntropy, complexity, diversity increase, and where local universal evolution culminates: the planetary life-complex. It is also the centre of the two velocity spirals, from where particular velocity ranges increase in both directions.
All of it is in harmony with the fundamental chord of the universe. Everything that we call "nature", and consider as if it would be something external, something unrelated to us, something that is there for us, superior human beings, to use and exploit, is existing within this fundamental harmony. Until all the "real human beings" realise, as their tribal ancestors did, that all their social, political and economic systems and all their secular and religious philosophies must be in tune with that fundamental harmony, there will be "system designers" flourishing on thinking up exploitive systems and their impressive system models and mathematical formulas, the social, political and economic disasters and widespread nihilism will continue within all the existing human cacophony.
I very much realise that the above presented ideas will please extremely few people, because the materialist credos do not allow "underlying principles" or "mind-stuff", replacing it with verbs manipulated into acting subjects (about which I can supply a host of examples both in cosmological and in evolutionary theories); and the religious credos accept only their particular dogmas about extrinsic anthropomorph god-images approachable through the theocratic hierarchy and knee-bent image-supplication or cross-legged navel-watching. I would be, however, very glad to receive some rational and constructive arguments.
Lei el link que mandaste. Me pareciera que no es nuestra postura (al menos hablo por mi) derribar ni ser un militante anti-reduccionista. El reduccionismo es una herramienta muuuy importante. Quizas lo que es mas interesante es observar los lugares donde el reduccionismo se queda corto.
Todos nosotros (creo) tenemos un background donde el reduccionismo es un lugar casi "natural". Para que no quede suelto en el aire y quede como que a nosotros solo nos gusta parlotear, especificamente en nuestro ambito, el reduccionismo es un lugar tipico y casi "natural".
A veces me pareciera que particionar la realidad, una y otra vez nos impide ver un panorama mas amplio. Nos "reducimos" nosotros. Tampoco se habla de no usar el reduccionismo, sino de tener cierto criterio. Poder entrar y salir de las partes. Hacer zoom y luego salir hacia arriba, indistintamente e intentar ver mas cabalmente como se articulan las cosas.
----- Original Message ----- From: "Imre v. Soos" <imre.soos@...> To: "Bertalanffy-list" <bertalanffy@...> Sent: Friday, January 09, 2009 1:48 PM Subject: [Bertalanffy] posting
Greetings All. I was delighted to hear that the Bertalanffy Discussion Forum was finally revived by Tom Mandel (hi Tom, it is nice to know that you are around), and that with a vital and fundamental question. After reading through all the correspondences, I am once more delighted to say that, this time, I am very much in agreement with him. Here are my thoughts on the subject:
"The comments so far are very interesting - as Tom wrote - but hardly form a consensus", because everybody appears to have a different concept behind the label. The reason for this are the various synonyms the word "system" has, like: scheme, organisation, arrangement, classification, structure, co-ordination, organism, method, technique, procedure, and even orderliness and logic. If all and everything these labels cover are being stuck under the label "system", than the answer is that all and everything is a system, and Tom wouldn't have popped the question.
The right approach would rest in Tom's further clarification: "What I had in mind when I asked the question was the integrative system, the kind where the elements work together and form from that a new whole. The question is important when we talk about integrative systems because the new whole is actually the emergent property of the relationships." Just as right is James Rose by stating that "GST addresses deeper principles and ideas - it challenges the methods of analysis themselves and how people think and assess what they encounter." - I will follow these lines of thoughts, because they coincide with my ideas.
Ever since the proton, neutron and electron - the three stable fundamental particles of all material manifestation - ceased to be "hard little balls" and became swirling energy-bundles of ordered processes in interwoven and interdependent harmonic system-relationships of energy-quantums; and the various intertwining and spinning processes of their harmonious interactions are forming the hundred or so stable elements; which, in turn, can constitute, according to their valency, innumerable chemical substances, stable molecules, "things" also ceased to be "things", and became harmonious, rational and productive "processes": dynamic systems of various orders of complexity.
The above chain of systems continues, in growing order of complexity, through macromolecules of aminoacids, organelles, cells, tissues, organs, germinal-organ-systems, organisms, ecological communities, planetary life-complex. Above the two directional linear interaction of the members of this chain, there exists also the perpendicular interaction of each member with those on its own level, rendering the planetary life-system to be a spatial concept.
I must stress the attribute "harmonious", because harmony is a fundamental factor in all constructive manifestation (as is "cacophony", its antagonistic opposite, a destructive, degenerative one); and is thus a foundation principle of the Universe. It produces monistic relationship - or inversely, monistic relationship represents harmony.
I must also stress the attribute "rational", because ad-hoc events cannot enter into and be parts of a harmonious relationship and cooperation.
And I must also stress "productive", as the necessary attribute of both the individual constituents, and of the new system of higher complexity they constitute.
Consequently, the concept 'system' - within the limits of the General System Research and Theory - should represent the harmonious, rational and productive interaction of constituting elements, forming, through these properties, a complete unit, that becomes thus more than the sum of its constituting elements, and that cannot be reduced to, or derived at through the analysis of any of its constituents.
The reducibility principle comes from what I must call a belief, that a system originates through the interaction of two or more material elements, and is the derivative of the qualities inherent in these constituting material elements, which themselves cause the interaction; and that, through their analysis, the whole system can be known and synthesised. In turn, this principle is based on the belief that the new system becomes, through the original interaction, just another "thing" but of higher complexity than are its constituting "things".
The "interaction" of the constituting elements does not represent the triggering off the "being" of a new system of higher complexity, but is a sine qua non constituent of the new system in form of its incessant process of "becoming", the cessation of which process would result in the immediate disintegration of the system into its constituting elements. Thus, the "interaction" itself is as much a constituting element of the derivative system, as are all the "material" ones, even if it is of non-material nature.
That the "interaction" itself is not of material nature, and that neither is it inherent in any of the constituting elements, I will illustrate with the simple example of water:
If a container is filled with a mixture of oxygen and hydrogen, the oxygen, being the heavier, will settle in the lower part, and the two gases will stay in that state side by side till doomsday, without ever changing their identity. Never will they turn themselves into water, or into hydrogen-hyperoxide, through an inherent, self-induced process. By introducing a spark or high pressure into this mixture, the consequent explosion will end up by joining two hydrogen and one oxygen atoms, to be held together by relatively strong (valence) forces, which compound, in consequence, will act as water molecules with completely different physical and chemical identity and distinctively new character, without any reference to that of any of its parts, which become unrecognisable in the new complex. This new "identity" manifests the underlying "mind-stuff", that transcends the constituting elements and is inherent in the derivative system.
At the first stratum of the Natural Order, where materialisations happen, where elementary matter (proton, neutron and electron) appear, formed out of electromagnetic energy-quantums by their particular ordering principles (the inferred, but unexplained 'virtual particles' of nuclear physics) into swirling energy-bundles of ordered processes (and where they can also disintegrate, leaving behind electromagnetic radiation), there exist only two constituents "interacting" to form the systems of elementary particles: free energy-quantums and their ordering principles that are not of material nature.
The further consideration that these ordered processes, consisting of energy and mind-stuff, are constituting the atoms of all the elements according to their particular ordering principles of the second order; and that a same kind of systematic procedure continues towards ever increasing complexities, brings to the conclusion, that free energy and differentiated underlying principle are the two common denominators of all the material manifestations; and that matter, in all its forms, is a structured process complex of by the mind ordered energy-fields at all levels of its manifestation, and that the Universe - as any part of it - is formed by order imposed over a primordial energy-soup by the Ordering Principle which pervades it. This idea, or rather knowledge, is expressed concisely by the Nobel laureate biologist George Wald of Harvard: "The stuff of the universe is mind stuff."
The planetary life-complex includes each and all of its constituents in systemic co-existence, from the elementary particles upwards. It is self-configuring and self-sustaining, being dependent only on the energy-source of the Sun.
For a system to function harmoniously, rationally and productively, its underlying principle, that animates the constituent parts into a system of higher complexity, must possess these qualities. I would go even further to state that a functional, natural system is alive at its own level of existence, due to its underlying mind-stuff being alive, conscious and intelligent at the level of its manifestation.
I suggest that from a universal point of view, an entity is alive if it partakes - at the level of its own being - as a subject, instrument and originator in the universal life-processes. Von Bertalanffy's and Woltereck's anamorphosis, i.e., tendency to create new forms of life; Schrödinger's feeding on negative entropy; Herrick's spontaneously developing states of greater heterogeneity and complexity; and Szent-Györgyi's syntropy, that is, innate drive in living matter to perfect itself, are clear manifestations of the will to live and the will to evolve.
Considering that, summarised: each system represents more than the sum of its parts; each system is constituted of systems of a lower order and its ordering principle; each system is an integral constituent of a system of a higher order; and that none of the systems can be reduced to any of its constituent parts; - a "system" is, in fact a holistic order, where the label "system" can be exchange with the label "holon" without altering anything on the general concept.
The Universe itself is a self-configuring system, where macrocosmic and microcosmic self-configurations are co-emergent and interdependent, and represent thus one self-evolving and self-maintaining system. While the evolution starts on the one extreme with the formation of elementary particles out of electromagnetic energy, the macrocosmic starts with the spatial distribution and ordering of these same elementary particles, developing the double helix by starting simultaneously from both extremes.
Thought, logic and creativity are as intrinsic in the microcosmic existence as in the macrocosmic one. Microcosmic logic and creativity is producing and is constantly juggling and reshuffling all the fundamental and ephemeral subatomic particles, without ever leaving any of it to chance, providing dependable building blocks, basic rules and ordered energy supplies for a universe with infinite varieties of form and action. Macrocosmic logic and creativity maintains and recreates space-time - the thought-form defining inertial behaviour of matter -, every instant altering its curvature according to the momentary state of distribution of matter in the universe; and keeps on manifesting itself in solar and galactic development, dynamic equilibrium and self-generated and self-sustained metabolic processes, as those of the whole universe. Within all the ordered turbulence, energy, coalesces into forms of inorganic and organic matter, composing the biological structure of living organisms able to support various levels of higher intelligences, and constituting the crystalline structure of their underlying ground. This particular reference frame is at the level of the greatest complexity and diversity within a universal system. It is the centre of the evolutionary double helix spiralling from the two infinite extremes: the point towards which syntropy, complexity, diversity increase, and where local universal evolution culminates: the planetary life-complex. It is also the centre of the two velocity spirals, from where particular velocity ranges increase in both directions.
All of it is in harmony with the fundamental chord of the universe. Everything that we call "nature", and consider as if it would be something external, something unrelated to us, something that is there for us, superior human beings, to use and exploit, is existing within this fundamental harmony. Until all the "real human beings" realise, as their tribal ancestors did, that all their social, political and economic systems and all their secular and religious philosophies must be in tune with that fundamental harmony, there will be "system designers" flourishing on thinking up exploitive systems and their impressive system models and mathematical formulas, the social, political and economic disasters and widespread nihilism will continue within all the existing human cacophony.
I very much realise that the above presented ideas will please extremely few people, because the materialist credos do not allow "underlying principles" or "mind-stuff", replacing it with verbs manipulated into acting subjects (about which I can supply a host of examples both in cosmological and in evolutionary theories); and the religious credos accept only their particular dogmas about extrinsic anthropomorph god-images approachable through the theocratic hierarchy and knee-bent image-supplication or cross-legged navel-watching. I would be, however, very glad to receive some rational and constructive arguments.
Pero solo por la convención que usan, que es __stdcall, segun leí en la pagina de microsoft, las funciones que usan esta convencion se decoran como '_xxxx@unNumero' donde el numero es el numero de bytes que ocupan los parametros de la funcion.
Yo implemete un función de reemplazo para la que me da problemas en el mismo archivo cpp y h. Esta funciona perfecto, y lo único que cambie es esto:
--- El jue 15-ene-09, Alejandro F. Reimondo <aleReimondo@...> escribió:
De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: jueves, 15 de enero de 2009, 10:17 pm

La DLL que ellos distribuyen tiene los nombres mangleados?
Creo que estas usando funciones de C++ y no la interfaz C...
(si definis el metodo api conun argumento mas al comienzo,
al debugear en C la funcion que usas... ves bien los argumentos?)
De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: lunes, 12 de enero de 2009, 2:08 pm
Hola Ale
Gracias eternamente jajajja, espero poder retribuir algún día.
Es tan dificil/caro ayudar así como producir usando un lenguaje sin compilar.
Si, me queda muy claro y por eso no pretendo nada.Estoy recaliente jajaja, solo porque me tengo que topar con estas cosas locas. Si lo hubiera querido, estoy seguro que no lo hubiera conseguido.
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel. Es triste que además las usen para resolver aplicaciones. .. la percepción de costos de producción y el éxito son siempre subjetivos.
Esto es lo que me contestaron hoy, tal vez nos quite la duda de que es realmente Jet3D.
The return value for the second one is constant. In addition, the first one has a calling convention of _stdcall instead of _cdecl (JETCC). You can find these types in BaseType.h. Check out that file and it will explain a lot.
Jet3D is a standard Windows DLL.
Pregunta obligada: Esto es optimo para usar desde ST ?.
Es lo mismo que decir libreria estandar C ?
Disculpa la pregunta boba, pero no estoy seguro.
A que lista te referís? Creo que pocas personas podrán ayudarte leyendo el mail... Es mas facil encontrar una escusa (por ejemplo que es smalltalk, o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie jajaja! por las vacaciones? yo diría que es por el frio! creo que la mayoría de la gente que podría ayudarte está bajo nieve en estos días... y quizás sin gas.
Quisiera creer que no es así, pero vos tenes mucha historia como para poder afirmarlo.
Saludos kiko
--- El sáb 10-ene-09, Alejandro F. Reimondo <aleReimondo@ smalltalking. net> escribió:
De: Alejandro F. Reimondo <aleReimondo@ smalltalking. net> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: sábado, 10 de enero de 2009, 11:32 am
Hola kiko,
>Gracias, se que estas ocupado y no te hagas drama.
jajaja! bienvenido el Sábado! releí un poco tus emails y creo que puedo darte algunas ideas mas... Igualmente, es muy dificil ayudar viendo código fuente; y no pudiendo hacer un doIt. Es tan dificil/caro ayudar así como producir usando un lenguaje sin compilar.
>Ya me inscribí a lista de VS y mande una consulta.
>Tambien pregunte en el foro de Jet3d http://apps. sourcefor >ge.net/phpbb/ jetpp/viewtopic. php?f=6&t= 19&sid >=5e782bf5b72568e49 22a9b4bc32428ff por si alguien quiere mirar >No es mucha la ayuda insiste en decirme que no apollan smalltalk.
jjaja
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel. Es triste que además las usen para resolver aplicaciones. .. la percepción de costos de producción y el éxito son siempre subjetivos.
>Pero seguramente debe haber mas gente trabajando en Vs en la lista ??.
A que lista te referís? Creo que pocas personas podrán ayudarte leyendo el mail... Es mas facil encontrar una escusa (por ejemplo que es smalltalk, o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie jajaja! por las vacaciones? yo diría que es por el frio! creo que la mayoría de la gente que podría ayudarte está bajo nieve en estos días... y quizás sin gas.
Bueno, volviendo a lo técnico....
Veo que tenes definida en la librería: >JETAPI const jeVec3d * JETCC jeBrush_FaceGetVert ByIndex(const jeBrush_Face >*Face, int32
Index) >{...}
Y que en Smalltalk tenes: >JetDLL>>jeBrushFac eGetVertByIndex: pJetBrushFace index: pIndex > <api: '_jeBrush_FaceGetVe rtByIndex@ 8' ulong ulong ulongReturn> > ^self invalidArgument
Para entender qué define la función en C es necesario saber cómo estan definidas las macros JETAPI, JETCCC que son parte de la parafernalia que se requiere para hacer algo "decorosamente" en Cpuspus. (Se que las pasaste por mail... lo digo para que estes seguro de que es lo que definen.. y que es <api: lo que corresponde)
Pero MAS IMPORTANTE AÚN es necesario saber dónde está definida la función!!! Según sospecho esta definida en una clase C++ y eso NO es una fución C!!!
Sospecho que el problema puede ser que la funcion que estas usando es una funcion (C++) de una clase y por eso esta mangleada. De ser así, podrías jakearlo del lado del smalltalk agregando un
(primer) parámetro, que sería el receptor del "mensaje" (mensaje que nunca se envía en C++)... NO te recomiendo hacerlo de esa forma (auqneu así seguramente te exlicarás el porque los argumentos son basura... estan desplazados :-) porque además debes fijarte si es correcto definir los métodos como <api: o <c: ... etc...
Si la función que estas usando fuera una función C no debería estar mangleada, es decir, si esta definida como jeBrush_FaceGetVert ByIndex(. .) el literal a usar en smalltalk DEBE ser 'jeBrush_FaceGetVer tByIndex'
Para verificar esto hace lo siguiente: 1.- asegurate de tener en el path bien instaladas las herramientas de cpuspus y compila nuevamente la DLL. 2.- hace un dump de la dll generada en un archivo de texto con algo asi: ------------ --dumpDLL. bat------ --------- ------- c:
------------ --------- --------- --------- --------- -- 3.- en el TXT fijate las funciones que estan exportadas, a modo de ejemplo te copio un pedazo de un txt de otro proyecto, pero que creo te servirá por analogía: ------------ --------- --------- --------- --------- -- Microsoft (R) COFF Binary File Dumper Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file d:\OpenCV1\Smalltal k\cv100d. dll File Type: DLL
Section contains the following exports for cv100d.dll ............ ......... ......... ......... ..... 461 number of functions 461 number of names
4.- fijate que las funciones de arriba están mangleadas, son exportadas porque el binding de runtime de C++ las necesita; ero no son las que deberías usar. Adeás de tenes exportadas funciones mangleadas, debes tener exportadas funciones C stabdard, sin manglear (sin caracteres ? _ ni
@)
5.- si no es así, debes escribir (es recomendable que lo hagas) en C funciones wrappers para exponar la API de la libreria en C.
Normalmente es una tarea muy simple en C y.... si no la hace el que escribe la librería es porque no quiere hacerlo (no quiere exponer la funcionalidad de una forma standard y abierta), como creo que es el caso de Jet3D (fijate que es lo que estan diciendote.. . yo creo que deberías escupirlos y decirles que vas a usar otra librería, sino van a seguri pensando que estan haciendo algo abierto, por el solo hecho de publicar los fuentes).
Volviendo a lo práctico... un afunción C++ no te serviría salvo que quieras jakearla, para eso deberías definir, como te decía, un primer argumento (que es el componente Cpuspus, el "this") de forma explisita, pues ese argumentos esta implisito en el lenguaje C++. Además deberías crear un objeto (que seguro ya lo tenes) del
lado de smalltalk que tenga ese puntero y además necesitas uan forma de instanciarlo. .. Para instanciar dicho objeto puede ocurrir que: 1.- tengas una funcion ya escrita en la librería que devuelva un puntero a dicha instancia (te devuelvela dirección del componente y eso es lo que guardas en tu objeto smalltalk, pasandolo luego como "self asParameter" como ese argumento que te falta) 2.- tengas que hacerte en la librería una funcion C que devuelva una nueva instancia.
OOPPPPPSSS!! ! ahora, leyendo nuevamente tu email, veo que estas usandola de la forma que note recomendaba :-) ok.. entonces tené cuidado porque apenas algo este "medio mal" te va a explotar todo :-)
Releyendo... vos decias.... >Esta es una función de Jet3D >JETAPI const jeVec3d * JETCC jeBrush_FaceGetVert ByIndex > (const jeBrush_Face *Face, int32 Index) .... >JetDLL>>jeBrushFac eGetVertByIndex:
pJetBrushFace index: pIndex > <api: '_jeBrush_FaceGetVe rtByIndex@ 8' ulong ulong ulongReturn> .... >OK .... >JetDLL>>jeBrushFac eSetVertByIndex: pJetBrushFace index: pIndex vertex: >pJetVertex > <api: '_jeBrush_FaceSetVe rtByIndex@ 12' ulong ulong struct none> .... >Ocurre que en la DLL el valor de vertex es basura !!!!!!!!!!!! !!. >Ahora si yo modifico el tipo de parametro de STRUCT a ULONG > el valor es correcto !!!!!!!!!!!! !.
Omitiste colocar la definicion en Cpuspus de la función SetVertByIndex. .. (o yo no la encontré... asumo que el argumento pJetVertex es un puntero a un vertex)
>Pero el tipo debería ser un STRUCT pues es un SelfDefinedStructur e >!!!!!!!!!!.
No. El argumento es un puntero, luego debe ser definido como un ulong (el puntero es lo que pasas, no toda la estructura.. . que copiaría su contenido a otro
lado)
>De otra manera si yo instanciara desde ST un JetVertex, al intentar > pasarlo a la DLL me diría que espera un ULONG !!!!!!!!!!.
Cuando te dice que espera un argumento definido de otra forma es que fallo la api porque los objetos que entraron en los argumentos no conforman la definición del método API, aún no salió de smalltalk... Es independiente de cómo sea la función en C en la librería. Si llega del lado de C mal, puede explotar pero no se chequea nada...
>Que tiene que ver el tipo de retorno CONST en la función ?.
Creo que nada (no deberías estar accediendo via Cpuspus sino via una API expuesta en C)
>Puede ser un problema para ST que se declare así es tipo de retorno ???.
jajaja... el problema podía ser si "no retorna" jajaja
>Puede ser un bug en la VM de ST ?.
No. Creo que es mal entendimiento de parte tuyo de cómo definir una API en el
caso que se te presenta ahora (que es un hacking y no un acceso a una funcion C standard) Lo seguro y decoroso es que quien hace la libreria haga su trabajo como corresponda y exponga una interfaz standard. Si no lo hace... yo no montaría mis esarrollos usando la librería o pagaría el precio de escribir la interfáz (agregando funciones estupidas del lado de C, como lo hace la gente que "trabaja bien" en esas herramientas) .
>O por el contrario es un comportamiento habitual ?.
Es habitual que uno se equivoque en situaciones de hacking; pero cuando le encontrás la vuelta luego siempre anda... es la unica ventaja de lo que "no puede cambiar" :-P
Estimados,
Por si no quedó claro...
la intension es armar una nomina de profesionales que
usan (o usaron) ALGUN smalltalk en producción.
No importa que versión de smalltalk sea (solo importa
tener un mínimo demostrable de dos años en algún
proyecto comercial).
Lo que comenté sobre VS, es porque así arrancó
esta idea, que hoy ha cambiado buscando ser
una lista que permita en un futuro cercano acercar
las personas con capacidad productiva a los lugares
dónde se produce con Smalltalk.
Ale.
----- Original Message -----
From: "Alejandro F. Reimondo" <aleReimondo@...>
To: <smalltalking@...>
Sent: Saturday, January 17, 2009 10:54 AM
Subject: Re: [objetos] Programadores Visual Smalltalk
> Muchas gracias a quienes estan enviando sus datos!
> Me es muy alentador el que aporten para armar
> esta nómina de profesionales que pueden
> trabajar en Smalltalk en nuestra región.
> Como retribución, estoy pensando en enviarles la
> lista (de forma privada) a quienes lo soliciten y
> hayan aportado sus datos.
> Además de los datos que había solicitado, pueden
> agregar si desean ser contactados de forma privada,
> en caso de haber posibilidades laborales y/o
> participación en proyectos de corto plazo;
> u otra info como página web, etc.
> Si no es mucho pedir, querría que reenvíen la solicitud,
> de forma personal (no como spam), a quienes sepan que
> tengan alguna experiencia trabajando con Smalltalk; sin
> animo de molestar o distraer, sino para que nadie deje de saber
> que puede ayudarnos a formar esta base de profesionales.
> hasta pronto,
> Ale.
>
>
> ----- Original Message -----
> From: "Alejandro F. Reimondo" <aleReimondo@...>
> To: <smalltalking@...>
> Sent: Thursday, January 15, 2009 10:10 PM
> Subject: [objetos] Programadores Visual Smalltalk
>
>
>> Hola,
>> En estos días estaba tratando de armar una lista de programadores
>> (Latinoamericanos) que tienen experiencia demostrable (no menor
>> a dos años) en Visual Smalltalk; y datos de actualidad, como por
>> ejemplo, si están trabajando con Visual Smalltalk o Dolphin;
>> si usan algún otro smalltalk para producir software y el/los
>> lugares en dónde trabajan actualmente...
>> Es un modesto comienzo de una nómina de especialistas
>> en la región, con el objeto de dar a conocer que plantel
>> productivo existe y ofrecer en el futuro esta información
>> a quienes necesitan personal especializado (entre otras cosas
>> que tengo en mente).
>> La empecé con Visual Smalltalk y Dolphin, pero agradecería
>> cualquier información (sin importar la version de smalltalk)
>> que ustedes pudieran enviarme para engrosar la lista (via
>> email personal).
>> No me refiero a un Curricullum Vitae, solo info de
>> datos básicos (nombre,email,direccion/telefono,
>> años de experiencia por c/versión,
>> comentario no mayor a tres renglones)
>> Considero que será muy positivo tener esa información
>> ya que hay tan poca gente con experiencia y no siempre
>> es facil recordar a quienes tienen interés en seguir trabajando
>> con Smalltalk.
>> gracias,
>> Ale
>> pdta.: tambien agradecería si hacen llegar este pedido
>> a personas de nuestra region que no estén en la lista
>> de Smalltalking.
>>
>>
>>
>> ------------------------------------
>>
>> Para más información sobre la Asociación escribir a info@...
>>
>> Smalltalking es un espacio colaborativo creado para el estudio y
>> desarrollo en Ambientes de Objetos.
>> Se sustenta gracias a la participación de sus socios.
>>
>> Las reglas de etiqueta sobre la lista están en
>> http://www.smalltalking.net/join/netiquete.htm
>> Enlaces a Yahoo! Grupos
>>
>>
>>
>>
>>
>>
>
>
>
> ------------------------------------
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
> desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
> Enlaces a Yahoo! Grupos
>
>
>
>
>
>
Muchas gracias a quienes estan enviando sus datos!
Me es muy alentador el que aporten para armar
esta nómina de profesionales que pueden
trabajar en Smalltalk en nuestra región.
Como retribución, estoy pensando en enviarles la
lista (de forma privada) a quienes lo soliciten y
hayan aportado sus datos.
Además de los datos que había solicitado, pueden
agregar si desean ser contactados de forma privada,
en caso de haber posibilidades laborales y/o
participación en proyectos de corto plazo;
u otra info como página web, etc.
Si no es mucho pedir, querría que reenvíen la solicitud,
de forma personal (no como spam), a quienes sepan que
tengan alguna experiencia trabajando con Smalltalk; sin
animo de molestar o distraer, sino para que nadie deje de saber
que puede ayudarnos a formar esta base de profesionales.
hasta pronto,
Ale.
----- Original Message -----
From: "Alejandro F. Reimondo" <aleReimondo@...>
To: <smalltalking@...>
Sent: Thursday, January 15, 2009 10:10 PM
Subject: [objetos] Programadores Visual Smalltalk
> Hola,
> En estos días estaba tratando de armar una lista de programadores
> (Latinoamericanos) que tienen experiencia demostrable (no menor
> a dos años) en Visual Smalltalk; y datos de actualidad, como por
> ejemplo, si están trabajando con Visual Smalltalk o Dolphin;
> si usan algún otro smalltalk para producir software y el/los
> lugares en dónde trabajan actualmente...
> Es un modesto comienzo de una nómina de especialistas
> en la región, con el objeto de dar a conocer que plantel
> productivo existe y ofrecer en el futuro esta información
> a quienes necesitan personal especializado (entre otras cosas
> que tengo en mente).
> La empecé con Visual Smalltalk y Dolphin, pero agradecería
> cualquier información (sin importar la version de smalltalk)
> que ustedes pudieran enviarme para engrosar la lista (via
> email personal).
> No me refiero a un Curricullum Vitae, solo info de
> datos básicos (nombre,email,direccion/telefono,
> años de experiencia por c/versión,
> comentario no mayor a tres renglones)
> Considero que será muy positivo tener esa información
> ya que hay tan poca gente con experiencia y no siempre
> es facil recordar a quienes tienen interés en seguir trabajando
> con Smalltalk.
> gracias,
> Ale
> pdta.: tambien agradecería si hacen llegar este pedido
> a personas de nuestra region que no estén en la lista
> de Smalltalking.
>
>
>
> ------------------------------------
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
> desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
> Enlaces a Yahoo! Grupos
>
>
>
>
>
>
----- Original Message ----- From: "Imre v. Soos" <imre.soos@aon.at> To: "Bertalanffy-list" <bertalanffy@bertalanffy.org> Sent: Friday, January 09, 2009 1:48 PM Subject: [Bertalanffy] posting
Greetings All. I was delighted to hear that the Bertalanffy Discussion Forum was finally revived by Tom Mandel (hi Tom, it is nice to know that you are around), and that with a vital and fundamental question. After reading through all the correspondences, I am once more delighted to say that, this time, I am very much in agreement with him. Here are my thoughts on the subject:
"The comments so far are very interesting - as Tom wrote - but hardly form a consensus", because everybody appears to have a different concept behind the label. The reason for this are the various synonyms the word "system" has, like: scheme, organisation, arrangement, classification, structure, co-ordination, organism, method, technique, procedure, and even orderliness and logic. If all and everything these labels cover are being stuck under the label "system", than the answer is that all and everything is a system, and Tom wouldn't have popped the question.
The right approach would rest in Tom's further clarification: "What I had in mind when I asked the question was the integrative system, the kind where the elements work together and form from that a new whole. The question is important when we talk about integrative systems because the new whole is actually the emergent property of the relationships." Just as right is James Rose by stating that "GST addresses deeper principles and ideas - it challenges the methods of analysis themselves and how people think and assess what they encounter." - I will follow these lines of thoughts, because they coincide with my ideas.
Ever since the proton, neutron and electron - the three stable fundamental particles of all material manifestation - ceased to be "hard little balls" and became swirling energy-bundles of ordered processes in interwoven and interdependent harmonic system-relationships of energy-quantums; and the various intertwining and spinning processes of their harmonious interactions are forming the hundred or so stable elements; which, in turn, can constitute, according to their valency, innumerable chemical substances, stable molecules, "things" also ceased to be "things", and became harmonious, rational and productive "processes": dynamic systems of various orders of complexity.
The above chain of systems continues, in growing order of complexity, through macromolecules of aminoacids, organelles, cells, tissues, organs, germinal-organ-systems, organisms, ecological communities, planetary life-complex. Above the two directional linear interaction of the members of this chain, there exists also the perpendicular interaction of each member with those on its own level, rendering the planetary life-system to be a spatial concept.
I must stress the attribute "harmonious", because harmony is a fundamental factor in all constructive manifestation (as is "cacophony", its antagonistic opposite, a destructive, degenerative one); and is thus a foundation principle of the Universe. It produces monistic relationship - or inversely, monistic relationship represents harmony.
I must also stress the attribute "rational", because ad-hoc events cannot enter into and be parts of a harmonious relationship and cooperation.
And I must also stress "productive", as the necessary attribute of both the individual constituents, and of the new system of higher complexity they constitute.
Consequently, the concept 'system' - within the limits of the General System Research and Theory - should represent the harmonious, rational and productive interaction of constituting elements, forming, through these properties, a complete unit, that becomes thus more than the sum of its constituting elements, and that cannot be reduced to, or derived at through the analysis of any of its constituents.
The reducibility principle comes from what I must call a belief, that a system originates through the interaction of two or more material elements, and is the derivative of the qualities inherent in these constituting material elements, which themselves cause the interaction; and that, through their analysis, the whole system can be known and synthesised. In turn, this principle is based on the belief that the new system becomes, through the original interaction, just another "thing" but of higher complexity than are its constituting "things".
The "interaction" of the constituting elements does not represent the triggering off the "being" of a new system of higher complexity, but is a sine qua non constituent of the new system in form of its incessant process of "becoming", the cessation of which process would result in the immediate disintegration of the system into its constituting elements. Thus, the "interaction" itself is as much a constituting element of the derivative system, as are all the "material" ones, even if it is of non-material nature.
That the "interaction" itself is not of material nature, and that neither is it inherent in any of the constituting elements, I will illustrate with the simple example of water:
If a container is filled with a mixture of oxygen and hydrogen, the oxygen, being the heavier, will settle in the lower part, and the two gases will stay in that state side by side till doomsday, without ever changing their identity. Never will they turn themselves into water, or into hydrogen-hyperoxide, through an inherent, self-induced process. By introducing a spark or high pressure into this mixture, the consequent explosion will end up by joining two hydrogen and one oxygen atoms, to be held together by relatively strong (valence) forces, which compound, in consequence, will act as water molecules with completely different physical and chemical identity and distinctively new character, without any reference to that of any of its parts, which become unrecognisable in the new complex. This new "identity" manifests the underlying "mind-stuff", that transcends the constituting elements and is inherent in the derivative system.
At the first stratum of the Natural Order, where materialisations happen, where elementary matter (proton, neutron and electron) appear, formed out of electromagnetic energy-quantums by their particular ordering principles (the inferred, but unexplained 'virtual particles' of nuclear physics) into swirling energy-bundles of ordered processes (and where they can also disintegrate, leaving behind electromagnetic radiation), there exist only two constituents "interacting" to form the systems of elementary particles: free energy-quantums and their ordering principles that are not of material nature.
The further consideration that these ordered processes, consisting of energy and mind-stuff, are constituting the atoms of all the elements according to their particular ordering principles of the second order; and that a same kind of systematic procedure continues towards ever increasing complexities, brings to the conclusion, that free energy and differentiated underlying principle are the two common denominators of all the material manifestations; and that matter, in all its forms, is a structured process complex of by the mind ordered energy-fields at all levels of its manifestation, and that the Universe - as any part of it - is formed by order imposed over a primordial energy-soup by the Ordering Principle which pervades it. This idea, or rather knowledge, is expressed concisely by the Nobel laureate biologist George Wald of Harvard: "The stuff of the universe is mind stuff."
The planetary life-complex includes each and all of its constituents in systemic co-existence, from the elementary particles upwards. It is self-configuring and self-sustaining, being dependent only on the energy-source of the Sun.
For a system to function harmoniously, rationally and productively, its underlying principle, that animates the constituent parts into a system of higher complexity, must possess these qualities. I would go even further to state that a functional, natural system is alive at its own level of existence, due to its underlying mind-stuff being alive, conscious and intelligent at the level of its manifestation.
I suggest that from a universal point of view, an entity is alive if it partakes - at the level of its own being - as a subject, instrument and originator in the universal life-processes. Von Bertalanffy's and Woltereck's anamorphosis, i.e., tendency to create new forms of life; Schrödinger's feeding on negative entropy; Herrick's spontaneously developing states of greater heterogeneity and complexity; and Szent-Györgyi's syntropy, that is, innate drive in living matter to perfect itself, are clear manifestations of the will to live and the will to evolve.
Considering that, summarised: each system represents more than the sum of its parts; each system is constituted of systems of a lower order and its ordering principle; each system is an integral constituent of a system of a higher order; and that none of the systems can be reduced to any of its constituent parts; - a "system" is, in fact a holistic order, where the label "system" can be exchange with the label "holon" without altering anything on the general concept.
The Universe itself is a self-configuring system, where macrocosmic and microcosmic self-configurations are co-emergent and interdependent, and represent thus one self-evolving and self-maintaining system. While the evolution starts on the one extreme with the formation of elementary particles out of electromagnetic energy, the macrocosmic starts with the spatial distribution and ordering of these same elementary particles, developing the double helix by starting simultaneously from both extremes.
Thought, logic and creativity are as intrinsic in the microcosmic existence as in the macrocosmic one. Microcosmic logic and creativity is producing and is constantly juggling and reshuffling all the fundamental and ephemeral subatomic particles, without ever leaving any of it to chance, providing dependable building blocks, basic rules and ordered energy supplies for a universe with infinite varieties of form and action. Macrocosmic logic and creativity maintains and recreates space-time - the thought-form defining inertial behaviour of matter -, every instant altering its curvature according to the momentary state of distribution of matter in the universe; and keeps on manifesting itself in solar and galactic development, dynamic equilibrium and self-generated and self-sustained metabolic processes, as those of the whole universe. Within all the ordered turbulence, energy, coalesces into forms of inorganic and organic matter, composing the biological structure of living organisms able to support various levels of higher intelligences, and constituting the crystalline structure of their underlying ground. This particular reference frame is at the level of the greatest complexity and diversity within a universal system. It is the centre of the evolutionary double helix spiralling from the two infinite extremes: the point towards which syntropy, complexity, diversity increase, and where local universal evolution culminates: the planetary life-complex. It is also the centre of the two velocity spirals, from where particular velocity ranges increase in both directions.
All of it is in harmony with the fundamental chord of the universe. Everything that we call "nature", and consider as if it would be something external, something unrelated to us, something that is there for us, superior human beings, to use and exploit, is existing within this fundamental harmony. Until all the "real human beings" realise, as their tribal ancestors did, that all their social, political and economic systems and all their secular and religious philosophies must be in tune with that fundamental harmony, there will be "system designers" flourishing on thinking up exploitive systems and their impressive system models and mathematical formulas, the social, political and economic disasters and widespread nihilism will continue within all the existing human cacophony.
I very much realise that the above presented ideas will please extremely few people, because the materialist credos do not allow "underlying principles" or "mind-stuff", replacing it with verbs manipulated into acting subjects (about which I can supply a host of examples both in cosmological and in evolutionary theories); and the religious credos accept only their particular dogmas about extrinsic anthropomorph god-images approachable through the theocratic hierarchy and knee-bent image-supplication or cross-legged navel-watching. I would be, however, very glad to receive some rational and constructive arguments.
De: kikoGregoris <kikogregoris@...> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: lunes, 12 de enero de 2009, 2:08 pm
Hola Ale
Gracias eternamente jajajja, espero poder retribuir algún día.
Es tan dificil/caro ayudar así como producir usando un lenguaje sin compilar.
Si, me queda muy claro y por eso no pretendo nada.Estoy recaliente jajaja, solo porque me tengo que topar con estas cosas locas. Si lo hubiera querido, estoy seguro que no lo hubiera conseguido.
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel. Es triste que además las usen para resolver aplicaciones. .. la percepción de costos de producción y el éxito son siempre subjetivos.
Esto es lo que me contestaron hoy, tal vez nos quite la duda de que es realmente Jet3D.
The return value for the second one is constant. In addition, the first one has a calling convention of _stdcall instead of _cdecl (JETCC). You can find these types in BaseType.h. Check out that file and it will explain a lot.
Jet3D is a standard Windows DLL.
Pregunta obligada: Esto es optimo para usar desde ST ?.
Es lo mismo que decir libreria estandar C ?
Disculpa la pregunta boba, pero no estoy seguro.
A que lista te referís? Creo que pocas personas podrán ayudarte leyendo el mail... Es mas facil encontrar una escusa (por ejemplo que es smalltalk, o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie jajaja! por las vacaciones? yo diría que es por el frio! creo que la mayoría de la gente que podría ayudarte está bajo nieve en estos días... y quizás sin gas.
Quisiera creer que no es así, pero vos tenes mucha historia como para poder afirmarlo.
Saludos kiko
--- El sáb 10-ene-09, Alejandro F. Reimondo <aleReimondo@ smalltalking. net> escribió:
De: Alejandro F. Reimondo <aleReimondo@ smalltalking. net> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: sábado, 10 de enero de 2009, 11:32 am
Hola kiko,
>Gracias, se que estas ocupado y no te hagas drama.
jajaja! bienvenido el Sábado! releí un poco tus emails y creo que puedo darte algunas ideas mas... Igualmente, es muy dificil ayudar viendo código fuente; y no pudiendo hacer un doIt. Es tan dificil/caro ayudar así como producir usando un lenguaje sin compilar.
>Ya me inscribí a lista de VS y mande una consulta.
>Tambien pregunte en el foro de Jet3d http://apps. sourcefor >ge.net/phpbb/ jetpp/viewtopic. php?f=6&t= 19&sid >=5e782bf5b72568e49 22a9b4bc32428ff por si alguien quiere mirar >No es mucha la ayuda insiste en decirme que no apollan smalltalk. jjaja
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel. Es triste que además las usen para resolver aplicaciones. .. la percepción de costos de producción y el éxito son siempre subjetivos.
>Pero seguramente debe haber mas gente trabajando en Vs en la lista ??.
A que lista te referís? Creo que pocas personas podrán ayudarte leyendo el mail... Es mas facil encontrar una escusa (por ejemplo que es smalltalk, o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie jajaja! por las vacaciones? yo diría que es por el frio! creo que la mayoría de la gente que podría ayudarte está bajo nieve en estos días... y quizás sin gas.
Bueno, volviendo a lo técnico....
Veo que tenes definida en la librería: >JETAPI const jeVec3d * JETCC jeBrush_FaceGetVert ByIndex(const jeBrush_Face >*Face, int32 Index) >{...}
Y que en Smalltalk tenes: >JetDLL>>jeBrushFac eGetVertByIndex: pJetBrushFace index: pIndex > <api: '_jeBrush_FaceGetVe rtByIndex@ 8' ulong ulong ulongReturn> > ^self invalidArgument
Para entender qué define la función en C es necesario saber cómo estan definidas las macros JETAPI, JETCCC que son parte de la parafernalia que se requiere para hacer algo "decorosamente" en Cpuspus. (Se que las pasaste por mail... lo digo para que estes seguro de que es lo que definen.. y que es <api: lo que corresponde)
Pero MAS IMPORTANTE AÚN es necesario saber dónde está definida la función!!! Según sospecho esta definida en una clase C++ y eso NO es una fución C!!!
Sospecho que el problema puede ser que la funcion que estas usando es una funcion (C++) de una clase y por eso esta mangleada. De ser así, podrías jakearlo del lado del smalltalk agregando un (primer) parámetro, que sería el receptor del "mensaje" (mensaje que nunca se envía en C++)... NO te recomiendo hacerlo de esa forma (auqneu así seguramente te exlicarás el porque los argumentos son basura... estan desplazados :-) porque además debes fijarte si es correcto definir los métodos como <api: o <c: ... etc...
Si la función que estas usando fuera una función C no debería estar mangleada, es decir, si esta definida como jeBrush_FaceGetVert ByIndex(. .) el literal a usar en smalltalk DEBE ser 'jeBrush_FaceGetVer tByIndex'
Para verificar esto hace lo siguiente: 1.- asegurate de tener en el path bien instaladas las herramientas de cpuspus y compila nuevamente la DLL. 2.- hace un dump de la dll generada en un archivo de texto con algo asi: ------------ --dumpDLL. bat------ --------- ------- c:
------------ --------- --------- --------- --------- -- 3.- en el TXT fijate las funciones que estan exportadas, a modo de ejemplo te copio un pedazo de un txt de otro proyecto, pero que creo te servirá por analogía: ------------ --------- --------- --------- --------- -- Microsoft (R) COFF Binary File Dumper Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file d:\OpenCV1\Smalltal k\cv100d. dll File Type: DLL
Section contains the following exports for cv100d.dll ............ ......... ......... ......... ..... 461 number of functions 461 number of names
4.- fijate que las funciones de arriba están mangleadas, son exportadas porque el binding de runtime de C++ las necesita; ero no son las que deberías usar. Adeás de tenes exportadas funciones mangleadas, debes tener exportadas funciones C stabdard, sin manglear (sin caracteres ? _ ni @)
5.- si no es así, debes escribir (es recomendable que lo hagas) en C funciones wrappers para exponar la API de la libreria en C.
Normalmente es una tarea muy simple en C y.... si no la hace el que escribe la librería es porque no quiere hacerlo (no quiere exponer la funcionalidad de una forma standard y abierta), como creo que es el caso de Jet3D (fijate que es lo que estan diciendote.. . yo creo que deberías escupirlos y decirles que vas a usar otra librería, sino van a seguri pensando que estan haciendo algo abierto, por el solo hecho de publicar los fuentes).
Volviendo a lo práctico... un afunción C++ no te serviría salvo que quieras jakearla, para eso deberías definir, como te decía, un primer argumento (que es el componente Cpuspus, el "this") de forma explisita, pues ese argumentos esta implisito en el lenguaje C++. Además deberías crear un objeto (que seguro ya lo tenes) del lado de smalltalk que tenga ese puntero y además necesitas uan forma de instanciarlo. .. Para instanciar dicho objeto puede ocurrir que: 1.- tengas una funcion ya escrita en la librería que devuelva un puntero a dicha instancia (te devuelvela dirección del componente y eso es lo que guardas en tu objeto smalltalk, pasandolo luego como "self asParameter" como ese argumento que te falta) 2.- tengas que hacerte en la librería una funcion C que devuelva una nueva instancia.
OOPPPPPSSS!! ! ahora, leyendo nuevamente tu email, veo que estas usandola de la forma que note recomendaba :-) ok.. entonces tené cuidado porque apenas algo este "medio mal" te va a explotar todo :-)
Releyendo... vos decias.... >Esta es una función de Jet3D >JETAPI const jeVec3d * JETCC jeBrush_FaceGetVert ByIndex > (const jeBrush_Face *Face, int32 Index) .... >JetDLL>>jeBrushFac eGetVertByIndex: pJetBrushFace index: pIndex > <api: '_jeBrush_FaceGetVe rtByIndex@ 8' ulong ulong ulongReturn> .... >OK .... >JetDLL>>jeBrushFac eSetVertByIndex: pJetBrushFace index: pIndex vertex: >pJetVertex > <api: '_jeBrush_FaceSetVe rtByIndex@ 12' ulong ulong struct none> .... >Ocurre que en la DLL el valor de vertex es basura !!!!!!!!!!!! !!. >Ahora si yo modifico el tipo de parametro de STRUCT a ULONG > el valor es correcto !!!!!!!!!!!! !.
Omitiste colocar la definicion en Cpuspus de la función SetVertByIndex. .. (o yo no la encontré... asumo que el argumento pJetVertex es un puntero a un vertex)
>Pero el tipo debería ser un STRUCT pues es un SelfDefinedStructur e >!!!!!!!!!!.
No. El argumento es un puntero, luego debe ser definido como un ulong (el puntero es lo que pasas, no toda la estructura.. . que copiaría su contenido a otro lado)
>De otra manera si yo instanciara desde ST un JetVertex, al intentar > pasarlo a la DLL me diría que espera un ULONG !!!!!!!!!!.
Cuando te dice que espera un argumento definido de otra forma es que fallo la api porque los objetos que entraron en los argumentos no conforman la definición del método API, aún no salió de smalltalk... Es independiente de cómo sea la función en C en la librería. Si llega del lado de C mal, puede explotar pero no se chequea nada...
>Que tiene que ver el tipo de retorno CONST en la función ?.
Creo que nada (no deberías estar accediendo via Cpuspus sino via una API expuesta en C)
>Puede ser un problema para ST que se declare así es tipo de retorno ???.
jajaja... el problema podía ser si "no retorna" jajaja
>Puede ser un bug en la VM de ST ?.
No. Creo que es mal entendimiento de parte tuyo de cómo definir una API en el caso que se te presenta ahora (que es un hacking y no un acceso a una funcion C standard) Lo seguro y decoroso es que quien hace la libreria haga su trabajo como corresponda y exponga una interfaz standard. Si no lo hace... yo no montaría mis esarrollos usando la librería o pagaría el precio de escribir la interfáz (agregando funciones estupidas del lado de C, como lo hace la gente que "trabaja bien" en esas herramientas) .
>O por el contrario es un comportamiento habitual ?.
Es habitual que uno se equivoque en situaciones de hacking; pero cuando le encontrás la vuelta luego siempre anda... es la unica ventaja de lo que "no puede cambiar" :-P
Hola,
En estos días estaba tratando de armar una lista de programadores
(Latinoamericanos) que tienen experiencia demostrable (no menor
a dos años) en Visual Smalltalk; y datos de actualidad, como por
ejemplo, si están trabajando con Visual Smalltalk o Dolphin;
si usan algún otro smalltalk para producir software y el/los
lugares en dónde trabajan actualmente...
Es un modesto comienzo de una nómina de especialistas
en la región, con el objeto de dar a conocer que plantel
productivo existe y ofrecer en el futuro esta información
a quienes necesitan personal especializado (entre otras cosas
que tengo en mente).
La empecé con Visual Smalltalk y Dolphin, pero agradecería
cualquier información (sin importar la version de smalltalk)
que ustedes pudieran enviarme para engrosar la lista (via
email personal).
No me refiero a un Curricullum Vitae, solo info de
datos básicos (nombre,email,direccion/telefono,
años de experiencia por c/versión,
comentario no mayor a tres renglones)
Considero que será muy positivo tener esa información
ya que hay tan poca gente con experiencia y no siempre
es facil recordar a quienes tienen interés en seguir trabajando
con Smalltalk.
gracias,
Ale
pdta.: tambien agradecería si hacen llegar este pedido
a personas de nuestra region que no estén en la lista
de Smalltalking.
----- Original Message ----- From: "Imre v. Soos" <imre.soos@aon.at> To: "Bertalanffy-list" <bertalanffy@bertalanffy.org> Sent: Friday, January 09, 2009 1:48 PM Subject: [Bertalanffy] posting
Greetings All. I was delighted to hear that the Bertalanffy Discussion Forum was finally revived by Tom Mandel (hi Tom, it is nice to know that you are around), and that with a vital and fundamental question. After reading through all the correspondences, I am once more delighted to say that, this time, I am very much in agreement with him. Here are my thoughts on the subject:
"The comments so far are very interesting - as Tom wrote - but hardly form a consensus", because everybody appears to have a different concept behind the label. The reason for this are the various synonyms the word "system" has, like: scheme, organisation, arrangement, classification, structure, co-ordination, organism, method, technique, procedure, and even orderliness and logic. If all and everything these labels cover are being stuck under the label "system", than the answer is that all and everything is a system, and Tom wouldn't have popped the question.
The right approach would rest in Tom's further clarification: "What I had in mind when I asked the question was the integrative system, the kind where the elements work together and form from that a new whole. The question is important when we talk about integrative systems because the new whole is actually the emergent property of the relationships." Just as right is James Rose by stating that "GST addresses deeper principles and ideas - it challenges the methods of analysis themselves and how people think and assess what they encounter." - I will follow these lines of thoughts, because they coincide with my ideas.
Ever since the proton, neutron and electron - the three stable fundamental particles of all material manifestation - ceased to be "hard little balls" and became swirling energy-bundles of ordered processes in interwoven and interdependent harmonic system-relationships of energy-quantums; and the various intertwining and spinning processes of their harmonious interactions are forming the hundred or so stable elements; which, in turn, can constitute, according to their valency, innumerable chemical substances, stable molecules, "things" also ceased to be "things", and became harmonious, rational and productive "processes": dynamic systems of various orders of complexity.
The above chain of systems continues, in growing order of complexity, through macromolecules of aminoacids, organelles, cells, tissues, organs, germinal-organ-systems, organisms, ecological communities, planetary life-complex. Above the two directional linear interaction of the members of this chain, there exists also the perpendicular interaction of each member with those on its own level, rendering the planetary life-system to be a spatial concept.
I must stress the attribute "harmonious", because harmony is a fundamental factor in all constructive manifestation (as is "cacophony", its antagonistic opposite, a destructive, degenerative one); and is thus a foundation principle of the Universe. It produces monistic relationship - or inversely, monistic relationship represents harmony.
I must also stress the attribute "rational", because ad-hoc events cannot enter into and be parts of a harmonious relationship and cooperation.
And I must also stress "productive", as the necessary attribute of both the individual constituents, and of the new system of higher complexity they constitute.
Consequently, the concept 'system' - within the limits of the General System Research and Theory - should represent the harmonious, rational and productive interaction of constituting elements, forming, through these properties, a complete unit, that becomes thus more than the sum of its constituting elements, and that cannot be reduced to, or derived at through the analysis of any of its constituents.
The reducibility principle comes from what I must call a belief, that a system originates through the interaction of two or more material elements, and is the derivative of the qualities inherent in these constituting material elements, which themselves cause the interaction; and that, through their analysis, the whole system can be known and synthesised. In turn, this principle is based on the belief that the new system becomes, through the original interaction, just another "thing" but of higher complexity than are its constituting "things".
The "interaction" of the constituting elements does not represent the triggering off the "being" of a new system of higher complexity, but is a sine qua non constituent of the new system in form of its incessant process of "becoming", the cessation of which process would result in the immediate disintegration of the system into its constituting elements. Thus, the "interaction" itself is as much a constituting element of the derivative system, as are all the "material" ones, even if it is of non-material nature.
That the "interaction" itself is not of material nature, and that neither is it inherent in any of the constituting elements, I will illustrate with the simple example of water:
If a container is filled with a mixture of oxygen and hydrogen, the oxygen, being the heavier, will settle in the lower part, and the two gases will stay in that state side by side till doomsday, without ever changing their identity. Never will they turn themselves into water, or into hydrogen-hyperoxide, through an inherent, self-induced process. By introducing a spark or high pressure into this mixture, the consequent explosion will end up by joining two hydrogen and one oxygen atoms, to be held together by relatively strong (valence) forces, which compound, in consequence, will act as water molecules with completely different physical and chemical identity and distinctively new character, without any reference to that of any of its parts, which become unrecognisable in the new complex. This new "identity" manifests the underlying "mind-stuff", that transcends the constituting elements and is inherent in the derivative system.
At the first stratum of the Natural Order, where materialisations happen, where elementary matter (proton, neutron and electron) appear, formed out of electromagnetic energy-quantums by their particular ordering principles (the inferred, but unexplained 'virtual particles' of nuclear physics) into swirling energy-bundles of ordered processes (and where they can also disintegrate, leaving behind electromagnetic radiation), there exist only two constituents "interacting" to form the systems of elementary particles: free energy-quantums and their ordering principles that are not of material nature.
The further consideration that these ordered processes, consisting of energy and mind-stuff, are constituting the atoms of all the elements according to their particular ordering principles of the second order; and that a same kind of systematic procedure continues towards ever increasing complexities, brings to the conclusion, that free energy and differentiated underlying principle are the two common denominators of all the material manifestations; and that matter, in all its forms, is a structured process complex of by the mind ordered energy-fields at all levels of its manifestation, and that the Universe - as any part of it - is formed by order imposed over a primordial energy-soup by the Ordering Principle which pervades it. This idea, or rather knowledge, is expressed concisely by the Nobel laureate biologist George Wald of Harvard: "The stuff of the universe is mind stuff."
The planetary life-complex includes each and all of its constituents in systemic co-existence, from the elementary particles upwards. It is self-configuring and self-sustaining, being dependent only on the energy-source of the Sun.
For a system to function harmoniously, rationally and productively, its underlying principle, that animates the constituent parts into a system of higher complexity, must possess these qualities. I would go even further to state that a functional, natural system is alive at its own level of existence, due to its underlying mind-stuff being alive, conscious and intelligent at the level of its manifestation.
I suggest that from a universal point of view, an entity is alive if it partakes - at the level of its own being - as a subject, instrument and originator in the universal life-processes. Von Bertalanffy's and Woltereck's anamorphosis, i.e., tendency to create new forms of life; Schrödinger's feeding on negative entropy; Herrick's spontaneously developing states of greater heterogeneity and complexity; and Szent-Györgyi's syntropy, that is, innate drive in living matter to perfect itself, are clear manifestations of the will to live and the will to evolve.
Considering that, summarised: each system represents more than the sum of its parts; each system is constituted of systems of a lower order and its ordering principle; each system is an integral constituent of a system of a higher order; and that none of the systems can be reduced to any of its constituent parts; - a "system" is, in fact a holistic order, where the label "system" can be exchange with the label "holon" without altering anything on the general concept.
The Universe itself is a self-configuring system, where macrocosmic and microcosmic self-configurations are co-emergent and interdependent, and represent thus one self-evolving and self-maintaining system. While the evolution starts on the one extreme with the formation of elementary particles out of electromagnetic energy, the macrocosmic starts with the spatial distribution and ordering of these same elementary particles, developing the double helix by starting simultaneously from both extremes.
Thought, logic and creativity are as intrinsic in the microcosmic existence as in the macrocosmic one. Microcosmic logic and creativity is producing and is constantly juggling and reshuffling all the fundamental and ephemeral subatomic particles, without ever leaving any of it to chance, providing dependable building blocks, basic rules and ordered energy supplies for a universe with infinite varieties of form and action. Macrocosmic logic and creativity maintains and recreates space-time - the thought-form defining inertial behaviour of matter -, every instant altering its curvature according to the momentary state of distribution of matter in the universe; and keeps on manifesting itself in solar and galactic development, dynamic equilibrium and self-generated and self-sustained metabolic processes, as those of the whole universe. Within all the ordered turbulence, energy, coalesces into forms of inorganic and organic matter, composing the biological structure of living organisms able to support various levels of higher intelligences, and constituting the crystalline structure of their underlying ground. This particular reference frame is at the level of the greatest complexity and diversity within a universal system. It is the centre of the evolutionary double helix spiralling from the two infinite extremes: the point towards which syntropy, complexity, diversity increase, and where local universal evolution culminates: the planetary life-complex. It is also the centre of the two velocity spirals, from where particular velocity ranges increase in both directions.
All of it is in harmony with the fundamental chord of the universe. Everything that we call "nature", and consider as if it would be something external, something unrelated to us, something that is there for us, superior human beings, to use and exploit, is existing within this fundamental harmony. Until all the "real human beings" realise, as their tribal ancestors did, that all their social, political and economic systems and all their secular and religious philosophies must be in tune with that fundamental harmony, there will be "system designers" flourishing on thinking up exploitive systems and their impressive system models and mathematical formulas, the social, political and economic disasters and widespread nihilism will continue within all the existing human cacophony.
I very much realise that the above presented ideas will please extremely few people, because the materialist credos do not allow "underlying principles" or "mind-stuff", replacing it with verbs manipulated into acting subjects (about which I can supply a host of examples both in cosmological and in evolutionary theories); and the religious credos accept only their particular dogmas about extrinsic anthropomorph god-images approachable through the theocratic hierarchy and knee-bent image-supplication or cross-legged navel-watching. I would be, however, very glad to receive some rational and constructive arguments.
Bueno, paradoxnj desarrollador de Jet3D respondio a lo que me interesaba saber.
Yes. Jet3D is a standard C DLL (same as Genesis).
Con lo que queda claro que se puede usar desde cualquier ST.
Ahora me queda lo mas dificil, saber porque diablos tengo esos problemas con la librería
saludos kiko
--- El lun 12-ene-09, kikoGregoris <kikogregoris@...> escribió:
De: kikoGregoris <kikogregoris@...> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: lunes, 12 de enero de 2009, 2:08 pm
Hola Ale
Gracias eternamente jajajja, espero poder retribuir algún día.
Es tan dificil/caro ayudar así como producir usando un lenguaje sin compilar.
Si, me queda muy claro y por eso no pretendo nada.Estoy recaliente jajaja, solo porque me tengo que topar con estas cosas locas. Si lo hubiera querido, estoy seguro que no lo hubiera conseguido.
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel. Es triste que además las usen para resolver aplicaciones. .. la percepción de costos de producción y el éxito son siempre subjetivos.
Esto es lo que me contestaron hoy, tal vez nos quite la duda de que es realmente Jet3D.
The return value for the second one is constant. In addition, the first one has a calling convention of _stdcall instead of _cdecl (JETCC). You can find these types in BaseType.h. Check out that file and it will explain a lot.
Jet3D is a standard Windows DLL.
Pregunta obligada: Esto es optimo para usar desde ST ?.
Es lo mismo que decir libreria estandar C ?
Disculpa la pregunta boba, pero no estoy seguro.
A que lista te referís? Creo que pocas personas podrán ayudarte leyendo el mail... Es mas facil encontrar una escusa (por ejemplo que es smalltalk, o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie jajaja! por las vacaciones? yo diría que es por el frio! creo que la mayoría de la gente que podría ayudarte está bajo nieve en estos días... y quizás sin gas.
Quisiera creer que no es así, pero vos tenes mucha historia como para poder afirmarlo.
Saludos kiko
--- El sáb 10-ene-09, Alejandro F. Reimondo <aleReimondo@ smalltalking. net> escribió:
De: Alejandro F. Reimondo <aleReimondo@ smalltalking. net> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: sábado, 10 de enero de 2009, 11:32 am
Hola kiko,
>Gracias, se que estas ocupado y no te hagas drama.
jajaja! bienvenido el Sábado! releí un poco tus emails y creo que puedo darte algunas ideas mas... Igualmente, es muy dificil ayudar viendo código fuente; y no pudiendo hacer un doIt. Es tan dificil/caro ayudar así como producir usando un lenguaje sin compilar.
>Ya me inscribí a lista de VS y mande una consulta.
>Tambien pregunte en el foro de Jet3d http://apps. sourcefor >ge.net/phpbb/ jetpp/viewtopic. php?f=6&t= 19&sid >=5e782bf5b72568e49 22a9b4bc32428ff por si alguien quiere mirar >No es mucha la ayuda insiste en decirme que no apollan smalltalk.
jjaja
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel. Es triste que además las usen para resolver aplicaciones. .. la percepción de costos de producción y el éxito son siempre subjetivos.
>Pero seguramente debe haber mas gente trabajando en Vs en la lista ??.
A que lista te referís? Creo que pocas personas podrán ayudarte leyendo el mail... Es mas facil encontrar una escusa (por ejemplo que es smalltalk, o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie jajaja! por las vacaciones? yo diría que es por el frio! creo que la mayoría de la gente que podría ayudarte está bajo nieve en estos días... y quizás sin gas.
Bueno, volviendo a lo técnico....
Veo que tenes definida en la librería: >JETAPI const jeVec3d * JETCC jeBrush_FaceGetVert ByIndex(const jeBrush_Face >*Face, int32
Index) >{...}
Y que en Smalltalk tenes: >JetDLL>>jeBrushFac eGetVertByIndex: pJetBrushFace index: pIndex > <api: '_jeBrush_FaceGetVe rtByIndex@ 8' ulong ulong ulongReturn> > ^self invalidArgument
Para entender qué define la función en C es necesario saber cómo estan definidas las macros JETAPI, JETCCC que son parte de la parafernalia que se requiere para hacer algo "decorosamente" en Cpuspus. (Se que las pasaste por mail... lo digo para que estes seguro de que es lo que definen.. y que es <api: lo que corresponde)
Pero MAS IMPORTANTE AÚN es necesario saber dónde está definida la función!!! Según sospecho esta definida en una clase C++ y eso NO es una fución C!!!
Sospecho que el problema puede ser que la funcion que estas usando es una funcion (C++) de una clase y por eso esta mangleada. De ser así, podrías jakearlo del lado del smalltalk agregando un
(primer) parámetro, que sería el receptor del "mensaje" (mensaje que nunca se envía en C++)... NO te recomiendo hacerlo de esa forma (auqneu así seguramente te exlicarás el porque los argumentos son basura... estan desplazados :-) porque además debes fijarte si es correcto definir los métodos como <api: o <c: ... etc...
Si la función que estas usando fuera una función C no debería estar mangleada, es decir, si esta definida como jeBrush_FaceGetVert ByIndex(. .) el literal a usar en smalltalk DEBE ser 'jeBrush_FaceGetVer tByIndex'
Para verificar esto hace lo siguiente: 1.- asegurate de tener en el path bien instaladas las herramientas de cpuspus y compila nuevamente la DLL. 2.- hace un dump de la dll generada en un archivo de texto con algo asi: ------------ --dumpDLL. bat------ --------- ------- c:
------------ --------- --------- --------- --------- -- 3.- en el TXT fijate las funciones que estan exportadas, a modo de ejemplo te copio un pedazo de un txt de otro proyecto, pero que creo te servirá por analogía: ------------ --------- --------- --------- --------- -- Microsoft (R) COFF Binary File Dumper Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file d:\OpenCV1\Smalltal k\cv100d. dll File Type: DLL
Section contains the following exports for cv100d.dll ............ ......... ......... ......... ..... 461 number of functions 461 number of names
4.- fijate que las funciones de arriba están mangleadas, son exportadas porque el binding de runtime de C++ las necesita; ero no son las que deberías usar. Adeás de tenes exportadas funciones mangleadas, debes tener exportadas funciones C stabdard, sin manglear (sin caracteres ? _ ni
@)
5.- si no es así, debes escribir (es recomendable que lo hagas) en C funciones wrappers para exponar la API de la libreria en C.
Normalmente es una tarea muy simple en C y.... si no la hace el que escribe la librería es porque no quiere hacerlo (no quiere exponer la funcionalidad de una forma standard y abierta), como creo que es el caso de Jet3D (fijate que es lo que estan diciendote.. . yo creo que deberías escupirlos y decirles que vas a usar otra librería, sino van a seguri pensando que estan haciendo algo abierto, por el solo hecho de publicar los fuentes).
Volviendo a lo práctico... un afunción C++ no te serviría salvo que quieras jakearla, para eso deberías definir, como te decía, un primer argumento (que es el componente Cpuspus, el "this") de forma explisita, pues ese argumentos esta implisito en el lenguaje C++. Además deberías crear un objeto (que seguro ya lo tenes) del
lado de smalltalk que tenga ese puntero y además necesitas uan forma de instanciarlo. .. Para instanciar dicho objeto puede ocurrir que: 1.- tengas una funcion ya escrita en la librería que devuelva un puntero a dicha instancia (te devuelvela dirección del componente y eso es lo que guardas en tu objeto smalltalk, pasandolo luego como "self asParameter" como ese argumento que te falta) 2.- tengas que hacerte en la librería una funcion C que devuelva una nueva instancia.
OOPPPPPSSS!! ! ahora, leyendo nuevamente tu email, veo que estas usandola de la forma que note recomendaba :-) ok.. entonces tené cuidado porque apenas algo este "medio mal" te va a explotar todo :-)
Releyendo... vos decias.... >Esta es una función de Jet3D >JETAPI const jeVec3d * JETCC jeBrush_FaceGetVert ByIndex > (const jeBrush_Face *Face, int32 Index) .... >JetDLL>>jeBrushFac eGetVertByIndex:
pJetBrushFace index: pIndex > <api: '_jeBrush_FaceGetVe rtByIndex@ 8' ulong ulong ulongReturn> .... >OK .... >JetDLL>>jeBrushFac eSetVertByIndex: pJetBrushFace index: pIndex vertex: >pJetVertex > <api: '_jeBrush_FaceSetVe rtByIndex@ 12' ulong ulong struct none> .... >Ocurre que en la DLL el valor de vertex es basura !!!!!!!!!!!! !!. >Ahora si yo modifico el tipo de parametro de STRUCT a ULONG > el valor es correcto !!!!!!!!!!!! !.
Omitiste colocar la definicion en Cpuspus de la función SetVertByIndex. .. (o yo no la encontré... asumo que el argumento pJetVertex es un puntero a un vertex)
>Pero el tipo debería ser un STRUCT pues es un SelfDefinedStructur e >!!!!!!!!!!.
No. El argumento es un puntero, luego debe ser definido como un ulong (el puntero es lo que pasas, no toda la estructura.. . que copiaría su contenido a otro
lado)
>De otra manera si yo instanciara desde ST un JetVertex, al intentar > pasarlo a la DLL me diría que espera un ULONG !!!!!!!!!!.
Cuando te dice que espera un argumento definido de otra forma es que fallo la api porque los objetos que entraron en los argumentos no conforman la definición del método API, aún no salió de smalltalk... Es independiente de cómo sea la función en C en la librería. Si llega del lado de C mal, puede explotar pero no se chequea nada...
>Que tiene que ver el tipo de retorno CONST en la función ?.
Creo que nada (no deberías estar accediendo via Cpuspus sino via una API expuesta en C)
>Puede ser un problema para ST que se declare así es tipo de retorno ???.
jajaja... el problema podía ser si "no retorna" jajaja
>Puede ser un bug en la VM de ST ?.
No. Creo que es mal entendimiento de parte tuyo de cómo definir una API en el
caso que se te presenta ahora (que es un hacking y no un acceso a una funcion C standard) Lo seguro y decoroso es que quien hace la libreria haga su trabajo como corresponda y exponga una interfaz standard. Si no lo hace... yo no montaría mis esarrollos usando la librería o pagaría el precio de escribir la interfáz (agregando funciones estupidas del lado de C, como lo hace la gente que "trabaja bien" en esas herramientas) .
>O por el contrario es un comportamiento habitual ?.
Es habitual que uno se equivoque en situaciones de hacking; pero cuando le encontrás la vuelta luego siempre anda... es la unica ventaja de lo que "no puede cambiar" :-P
Lo relei. Me hubiera gustado que hable tambien que papel juega lo temporal en los sistemas. Por ej:
"The Universe itself is a self-configuring system, where macrocosmic and
microcosmic self-configurations are co-emergent and interdependent, and
represent thus one self-evolving and self-maintaining system. While the
evolution starts on the one extreme with the formation of elementary
particles out of electromagnetic energy, the macrocosmic starts with the
spatial distribution and ordering of these same elementary particles,
developing the double helix by starting simultaneously from both extremes."
El "self-configuring" la auto organizacion, sucede en una temporalidad. Seguramente los sistemas estan intrinsecamente relacionados, con la trama espacio-tiempo. No me lo tomen como un divague. Los sitemas tienen un contexto y ese contexto lo va influenciando, de manera que realmente esta implicado en la trama del espacio. Esta unido al entramado en donde sucede, es parte del entramado. Los acontecimientos y el fluir de la actividad del sistema se da en una temporalidad.
Me es dificil pensar en los sistemas naturales y/o complejos evitando hablar de lo temporal. El tema del tiempo esta implicito en lo que dice el chavon este, pero no se explaya en el tema.
Lastima (o no :-D ) que esta noche me voy de vacaciones. Me genera muchas inquietudes esto. Esta piola.
Aque se refiere con "mind-stuff" en este contexto?? Por ejemplo, aca:
"
If a container is filled with a mixture of oxygen and hydrogen, the oxygen,
being the heavier, will settle in the lower part, and the two gases will
stay in that state side by side till doomsday, without ever changing their
identity. Never will they turn themselves into water, or into
hydrogen-hyperoxide, through an inherent, self-induced process. By
introducing a spark or high pressure into this mixture, the consequent
explosion will end up by joining two hydrogen and one oxygen atoms, to be
held together by relatively strong (valence) forces, which compound, in
consequence, will act as water molecules with completely different physical
and chemical identity and distinctively new character, without any reference
to that of any of its parts, which become unrecognisable in the new complex.
This new "identity" manifests the underlying "mind-stuff", that transcends
the constituting elements and is inherent in the derivative system."
Este otro pasaje me hace acordar un poco a las cosas que Carl Sagan:
"
All of it is in harmony with the fundamental chord of the universe.
Everything that we call "nature", and consider as if it would be something
external, something unrelated to us, something that is there for us,
superior human beings, to use and exploit, is existing within this
fundamental harmony. Until all the "real human beings" realise, as their
tribal ancestors did, that all their social, political and economic systems
and all their secular and religious philosophies must be in tune with that
fundamental harmony, there will be "system designers" flourishing on
thinking up exploitive systems and their impressive system models and
mathematical formulas, the social, political and economic disasters and
widespread nihilism will continue within all the existing human cacophony."
----- Original Message -----
From: "Imre v. Soos" <imre.soos@...>
To: "Bertalanffy-list" <bertalanffy@...>
Sent: Friday, January 09, 2009 1:48 PM
Subject: [Bertalanffy] posting
Greetings All. I was delighted to hear that the Bertalanffy Discussion Forum
was finally revived by Tom Mandel (hi Tom, it is nice to know that you are
around), and that with a vital and fundamental question. After reading
through all the correspondences, I am once more delighted to say that, this
time, I am very much in agreement with him. Here are my thoughts on the
subject:
"The comments so far are very interesting - as Tom wrote - but hardly form a
consensus", because everybody appears to have a different concept behind the
label. The reason for this are the various synonyms the word "system" has,
like: scheme, organisation, arrangement, classification, structure,
co-ordination, organism, method, technique, procedure, and even orderliness
and logic. If all and everything these labels cover are being stuck under
the label "system", than the answer is that all and everything is a system,
and Tom wouldn't have popped the question.
The right approach would rest in Tom's further clarification: "What I had in
mind when I asked the question was the integrative system, the kind where
the elements work together and form from that a new whole. The question is
important when we talk about integrative systems because the new whole is
actually the emergent property of the relationships." Just as right is James
Rose by stating that "GST addresses deeper principles and ideas - it
challenges the methods of analysis themselves and how people think and
assess what they encounter." - I will follow these lines of thoughts,
because they coincide with my ideas.
Ever since the proton, neutron and electron - the three stable fundamental
particles of all material manifestation - ceased to be "hard little balls"
and became swirling energy-bundles of ordered processes in interwoven and
interdependent harmonic system-relationships of energy-quantums; and the
various intertwining and spinning processes of their harmonious interactions
are forming the hundred or so stable elements; which, in turn, can
constitute, according to their valency, innumerable chemical substances,
stable molecules, "things" also ceased to be "things", and became
harmonious, rational and productive "processes": dynamic systems of various
orders of complexity.
The above chain of systems continues, in growing order of complexity,
through macromolecules of aminoacids, organelles, cells, tissues, organs,
germinal-organ-systems, organisms, ecological communities, planetary
life-complex. Above the two directional linear interaction of the members of
this chain, there exists also the perpendicular interaction of each member
with those on its own level, rendering the planetary life-system to be a
spatial concept.
I must stress the attribute "harmonious", because harmony is a fundamental
factor in all constructive manifestation (as is "cacophony", its
antagonistic opposite, a destructive, degenerative one); and is thus a
foundation principle of the Universe. It produces monistic relationship - or
inversely, monistic relationship represents harmony.
I must also stress the attribute "rational", because ad-hoc events cannot
enter into and be parts of a harmonious relationship and cooperation.
And I must also stress "productive", as the necessary attribute of both the
individual constituents, and of the new system of higher complexity they
constitute.
Consequently, the concept 'system' - within the limits of the General System
Research and Theory - should represent the harmonious, rational and
productive interaction of constituting elements, forming, through these
properties, a complete unit, that becomes thus more than the sum of its
constituting elements, and that cannot be reduced to, or derived at through
the analysis of any of its constituents.
The reducibility principle comes from what I must call a belief, that a
system originates through the interaction of two or more material elements,
and is the derivative of the qualities inherent in these constituting
material elements, which themselves cause the interaction; and that, through
their analysis, the whole system can be known and synthesised. In turn, this
principle is based on the belief that the new system becomes, through the
original interaction, just another "thing" but of higher complexity than are
its constituting "things".
The "interaction" of the constituting elements does not represent the
triggering off the "being" of a new system of higher complexity, but is a
sine qua non constituent of the new system in form of its incessant process
of "becoming", the cessation of which process would result in the immediate
disintegration of the system into its constituting elements. Thus, the
"interaction" itself is as much a constituting element of the derivative
system, as are all the "material" ones, even if it is of non-material
nature.
That the "interaction" itself is not of material nature, and that neither is
it inherent in any of the constituting elements, I will illustrate with the
simple example of water:
If a container is filled with a mixture of oxygen and hydrogen, the oxygen,
being the heavier, will settle in the lower part, and the two gases will
stay in that state side by side till doomsday, without ever changing their
identity. Never will they turn themselves into water, or into
hydrogen-hyperoxide, through an inherent, self-induced process. By
introducing a spark or high pressure into this mixture, the consequent
explosion will end up by joining two hydrogen and one oxygen atoms, to be
held together by relatively strong (valence) forces, which compound, in
consequence, will act as water molecules with completely different physical
and chemical identity and distinctively new character, without any reference
to that of any of its parts, which become unrecognisable in the new complex.
This new "identity" manifests the underlying "mind-stuff", that transcends
the constituting elements and is inherent in the derivative system.
At the first stratum of the Natural Order, where materialisations happen,
where elementary matter (proton, neutron and electron) appear, formed out of
electromagnetic energy-quantums by their particular ordering principles (the
inferred, but unexplained 'virtual particles' of nuclear physics) into
swirling energy-bundles of ordered processes (and where they can also
disintegrate, leaving behind electromagnetic radiation), there exist only
two constituents "interacting" to form the systems of elementary particles:
free energy-quantums and their ordering principles that are not of material
nature.
The further consideration that these ordered processes, consisting of energy
and mind-stuff, are constituting the atoms of all the elements according to
their particular ordering principles of the second order; and that a same
kind of systematic procedure continues towards ever increasing complexities,
brings to the conclusion, that free energy and differentiated underlying
principle are the two common denominators of all the material
manifestations; and that matter, in all its forms, is a structured process
complex of by the mind ordered energy-fields at all levels of its
manifestation, and that the Universe - as any part of it - is formed by
order imposed over a primordial energy-soup by the Ordering Principle which
pervades it. This idea, or rather knowledge, is expressed concisely by the
Nobel laureate biologist George Wald of Harvard: "The stuff of the universe
is mind stuff."
The planetary life-complex includes each and all of its constituents in
systemic co-existence, from the elementary particles upwards. It is
self-configuring and self-sustaining, being dependent only on the
energy-source of the Sun.
For a system to function harmoniously, rationally and productively, its
underlying principle, that animates the constituent parts into a system of
higher complexity, must possess these qualities. I would go even further to
state that a functional, natural system is alive at its own level of
existence, due to its underlying mind-stuff being alive, conscious and
intelligent at the level of its manifestation.
I suggest that from a universal point of view, an entity is alive if it
partakes - at the level of its own being - as a subject, instrument and
originator in the universal life-processes. Von Bertalanffy's and
Woltereck's anamorphosis, i.e., tendency to create new forms of life;
Schrödinger's feeding on negative entropy; Herrick's spontaneously
developing states of greater heterogeneity and complexity; and
Szent-Györgyi's syntropy, that is, innate drive in living matter to perfect
itself, are clear manifestations of the will to live and the will to evolve.
Considering that, summarised: each system represents more than the sum of
its parts; each system is constituted of systems of a lower order and its
ordering principle; each system is an integral constituent of a system of a
higher order; and that none of the systems can be reduced to any of its
constituent parts; - a "system" is, in fact a holistic order, where the
label "system" can be exchange with the label "holon" without altering
anything on the general concept.
The Universe itself is a self-configuring system, where macrocosmic and
microcosmic self-configurations are co-emergent and interdependent, and
represent thus one self-evolving and self-maintaining system. While the
evolution starts on the one extreme with the formation of elementary
particles out of electromagnetic energy, the macrocosmic starts with the
spatial distribution and ordering of these same elementary particles,
developing the double helix by starting simultaneously from both extremes.
Thought, logic and creativity are as intrinsic in the microcosmic existence
as in the macrocosmic one. Microcosmic logic and creativity is producing and
is constantly juggling and reshuffling all the fundamental and ephemeral
subatomic particles, without ever leaving any of it to chance, providing
dependable building blocks, basic rules and ordered energy supplies for a
universe with infinite varieties of form and action. Macrocosmic logic and
creativity maintains and recreates space-time - the thought-form defining
inertial behaviour of matter -, every instant altering its curvature
according to the momentary state of distribution of matter in the universe;
and keeps on manifesting itself in solar and galactic development, dynamic
equilibrium and self-generated and self-sustained metabolic processes, as
those of the whole universe. Within all the ordered turbulence, energy,
coalesces into forms of inorganic and organic matter, composing the
biological structure of living organisms able to support various levels of
higher intelligences, and constituting the crystalline structure of their
underlying ground. This particular reference frame is at the level of the
greatest complexity and diversity within a universal system. It is the
centre of the evolutionary double helix spiralling from the two infinite
extremes: the point towards which syntropy, complexity, diversity increase,
and where local universal evolution culminates: the planetary life-complex.
It is also the centre of the two velocity spirals, from where particular
velocity ranges increase in both directions.
All of it is in harmony with the fundamental chord of the universe.
Everything that we call "nature", and consider as if it would be something
external, something unrelated to us, something that is there for us,
superior human beings, to use and exploit, is existing within this
fundamental harmony. Until all the "real human beings" realise, as their
tribal ancestors did, that all their social, political and economic systems
and all their secular and religious philosophies must be in tune with that
fundamental harmony, there will be "system designers" flourishing on
thinking up exploitive systems and their impressive system models and
mathematical formulas, the social, political and economic disasters and
widespread nihilism will continue within all the existing human cacophony.
I very much realise that the above presented ideas will please extremely few
people, because the materialist credos do not allow "underlying principles"
or "mind-stuff", replacing it with verbs manipulated into acting subjects
(about which I can supply a host of examples both in cosmological and in
evolutionary theories); and the religious credos accept only their
particular dogmas about extrinsic anthropomorph god-images approachable
through the theocratic hierarchy and knee-bent image-supplication or
cross-legged navel-watching. I would be, however, very glad to receive some
rational and constructive arguments.
Gracias eternamente jajajja, espero poder retribuir algún día.
Es tan dificil/caro ayudar así como producir usando un lenguaje sin compilar.
Si, me queda muy claro y por eso no pretendo nada.Estoy recaliente jajaja, solo porque me tengo que topar con estas cosas locas. Si lo hubiera querido, estoy seguro que no lo hubiera conseguido.
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel. Es triste que además las usen para resolver aplicaciones. .. la percepción de costos de producción y el éxito son siempre subjetivos.
Esto es lo que me contestaron hoy, tal vez nos quite la duda de que es realmente Jet3D.
The return value for the second one is constant. In addition, the first one has a calling convention of _stdcall instead of _cdecl (JETCC). You can find these types in BaseType.h. Check out that file and it will explain a lot.
Jet3D is a standard Windows DLL.
Pregunta obligada: Esto es optimo para usar desde ST ?.
Es lo mismo que decir libreria estandar C ?
Disculpa la pregunta boba, pero no estoy seguro.
A que lista te referís? Creo que pocas personas podrán ayudarte leyendo el mail... Es mas facil encontrar una escusa (por ejemplo que es smalltalk, o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie jajaja! por las vacaciones? yo diría que es por el frio! creo que la mayoría de la gente que podría ayudarte está bajo nieve en estos días... y quizás sin gas.
Quisiera creer que no es así, pero vos tenes mucha historia como para poder afirmarlo.
Saludos kiko
--- El sáb 10-ene-09, Alejandro F. Reimondo <aleReimondo@...> escribió:
De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: sábado, 10 de enero de 2009, 11:32 am
Hola kiko,
>Gracias, se que estas ocupado y no te hagas drama.
jajaja! bienvenido el Sábado! releí un poco tus emails y creo que puedo darte algunas ideas mas... Igualmente, es muy dificil ayudar viendo código fuente; y no pudiendo hacer un doIt. Es tan dificil/caro ayudar así como producir usando un lenguaje sin compilar.
>Ya me inscribí a lista de VS y mande una consulta.
>Tambien pregunte en el foro de Jet3d http://apps. sourcefor >ge.net/phpbb/ jetpp/viewtopic. php?f=6&t= 19&sid >=5e782bf5b72568e49 22a9b4bc32428ff por si alguien quiere mirar >No es mucha la ayuda insiste en decirme que no apollan smalltalk.
jjaja
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel. Es triste que además las usen para resolver aplicaciones. .. la percepción de costos de producción y el éxito son siempre subjetivos.
>Pero seguramente debe haber mas gente trabajando en Vs en la lista ??.
A que lista te referís? Creo que pocas personas podrán ayudarte leyendo el mail... Es mas facil encontrar una escusa (por ejemplo que es smalltalk, o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie jajaja! por las vacaciones? yo diría que es por el frio! creo que la mayoría de la gente que podría ayudarte está bajo nieve en estos días... y quizás sin gas.
Bueno, volviendo a lo técnico....
Veo que tenes definida en la librería: >JETAPI const jeVec3d * JETCC jeBrush_FaceGetVert ByIndex(const jeBrush_Face >*Face, int32
Index) >{...}
Y que en Smalltalk tenes: >JetDLL>>jeBrushFac eGetVertByIndex: pJetBrushFace index: pIndex > <api: '_jeBrush_FaceGetVe rtByIndex@ 8' ulong ulong ulongReturn> > ^self invalidArgument
Para entender qué define la función en C es necesario saber cómo estan definidas las macros JETAPI, JETCCC que son parte de la parafernalia que se requiere para hacer algo "decorosamente" en Cpuspus. (Se que las pasaste por mail... lo digo para que estes seguro de que es lo que definen.. y que es <api: lo que corresponde)
Pero MAS IMPORTANTE AÚN es necesario saber dónde está definida la función!!! Según sospecho esta definida en una clase C++ y eso NO es una fución C!!!
Sospecho que el problema puede ser que la funcion que estas usando es una funcion (C++) de una clase y por eso esta mangleada. De ser así, podrías jakearlo del lado del smalltalk agregando un
(primer) parámetro, que sería el receptor del "mensaje" (mensaje que nunca se envía en C++)... NO te recomiendo hacerlo de esa forma (auqneu así seguramente te exlicarás el porque los argumentos son basura... estan desplazados :-) porque además debes fijarte si es correcto definir los métodos como <api: o <c: ... etc...
Si la función que estas usando fuera una función C no debería estar mangleada, es decir, si esta definida como jeBrush_FaceGetVert ByIndex(. .) el literal a usar en smalltalk DEBE ser 'jeBrush_FaceGetVer tByIndex'
Para verificar esto hace lo siguiente: 1.- asegurate de tener en el path bien instaladas las herramientas de cpuspus y compila nuevamente la DLL. 2.- hace un dump de la dll generada en un archivo de texto con algo asi: ------------ --dumpDLL. bat------ --------- ------- c:
------------ --------- --------- --------- --------- -- 3.- en el TXT fijate las funciones que estan exportadas, a modo de ejemplo te copio un pedazo de un txt de otro proyecto, pero que creo te servirá por analogía: ------------ --------- --------- --------- --------- -- Microsoft (R) COFF Binary File Dumper Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file d:\OpenCV1\Smalltal k\cv100d. dll File Type: DLL
Section contains the following exports for cv100d.dll ............ ......... ......... ......... ..... 461 number of functions 461 number of names
4.- fijate que las funciones de arriba están mangleadas, son exportadas porque el binding de runtime de C++ las necesita; ero no son las que deberías usar. Adeás de tenes exportadas funciones mangleadas, debes tener exportadas funciones C stabdard, sin manglear (sin caracteres ? _ ni
@)
5.- si no es así, debes escribir (es recomendable que lo hagas) en C funciones wrappers para exponar la API de la libreria en C.
Normalmente es una tarea muy simple en C y.... si no la hace el que escribe la librería es porque no quiere hacerlo (no quiere exponer la funcionalidad de una forma standard y abierta), como creo que es el caso de Jet3D (fijate que es lo que estan diciendote.. . yo creo que deberías escupirlos y decirles que vas a usar otra librería, sino van a seguri pensando que estan haciendo algo abierto, por el solo hecho de publicar los fuentes).
Volviendo a lo práctico... un afunción C++ no te serviría salvo que quieras jakearla, para eso deberías definir, como te decía, un primer argumento (que es el componente Cpuspus, el "this") de forma explisita, pues ese argumentos esta implisito en el lenguaje C++. Además deberías crear un objeto (que seguro ya lo tenes) del
lado de smalltalk que tenga ese puntero y además necesitas uan forma de instanciarlo. .. Para instanciar dicho objeto puede ocurrir que: 1.- tengas una funcion ya escrita en la librería que devuelva un puntero a dicha instancia (te devuelvela dirección del componente y eso es lo que guardas en tu objeto smalltalk, pasandolo luego como "self asParameter" como ese argumento que te falta) 2.- tengas que hacerte en la librería una funcion C que devuelva una nueva instancia.
OOPPPPPSSS!! ! ahora, leyendo nuevamente tu email, veo que estas usandola de la forma que note recomendaba :-) ok.. entonces tené cuidado porque apenas algo este "medio mal" te va a explotar todo :-)
Releyendo... vos decias.... >Esta es una función de Jet3D >JETAPI const jeVec3d * JETCC jeBrush_FaceGetVert ByIndex > (const jeBrush_Face *Face, int32 Index) .... >JetDLL>>jeBrushFac eGetVertByIndex:
pJetBrushFace index: pIndex > <api: '_jeBrush_FaceGetVe rtByIndex@ 8' ulong ulong ulongReturn> .... >OK .... >JetDLL>>jeBrushFac eSetVertByIndex: pJetBrushFace index: pIndex vertex: >pJetVertex > <api: '_jeBrush_FaceSetVe rtByIndex@ 12' ulong ulong struct none> .... >Ocurre que en la DLL el valor de vertex es basura !!!!!!!!!!!! !!. >Ahora si yo modifico el tipo de parametro de STRUCT a ULONG > el valor es correcto !!!!!!!!!!!! !.
Omitiste colocar la definicion en Cpuspus de la función SetVertByIndex. .. (o yo no la encontré... asumo que el argumento pJetVertex es un puntero a un vertex)
>Pero el tipo debería ser un STRUCT pues es un SelfDefinedStructur e >!!!!!!!!!!.
No. El argumento es un puntero, luego debe ser definido como un ulong (el puntero es lo que pasas, no toda la estructura.. . que copiaría su contenido a otro
lado)
>De otra manera si yo instanciara desde ST un JetVertex, al intentar > pasarlo a la DLL me diría que espera un ULONG !!!!!!!!!!.
Cuando te dice que espera un argumento definido de otra forma es que fallo la api porque los objetos que entraron en los argumentos no conforman la definición del método API, aún no salió de smalltalk... Es independiente de cómo sea la función en C en la librería. Si llega del lado de C mal, puede explotar pero no se chequea nada...
>Que tiene que ver el tipo de retorno CONST en la función ?.
Creo que nada (no deberías estar accediendo via Cpuspus sino via una API expuesta en C)
>Puede ser un problema para ST que se declare así es tipo de retorno ???.
jajaja... el problema podía ser si "no retorna" jajaja
>Puede ser un bug en la VM de ST ?.
No. Creo que es mal entendimiento de parte tuyo de cómo definir una API en el
caso que se te presenta ahora (que es un hacking y no un acceso a una funcion C standard) Lo seguro y decoroso es que quien hace la libreria haga su trabajo como corresponda y exponga una interfaz standard. Si no lo hace... yo no montaría mis esarrollos usando la librería o pagaría el precio de escribir la interfáz (agregando funciones estupidas del lado de C, como lo hace la gente que "trabaja bien" en esas herramientas) .
>O por el contrario es un comportamiento habitual ?.
Es habitual que uno se equivoque en situaciones de hacking; pero cuando le encontrás la vuelta luego siempre anda... es la unica ventaja de lo que "no puede cambiar" :-P
>Se entiende el dilema ? jajaj
suerte! espero te sirva mi larrrrrgo email Ale.
Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer.yahoo.com/cocina/
Mas material para la reunión? :-)
Ale.
----- Original Message -----
From: "Imre v. Soos" <imre.soos@...>
To: "Bertalanffy-list" <bertalanffy@...>
Sent: Friday, January 09, 2009 1:48 PM
Subject: [Bertalanffy] posting
Greetings All. I was delighted to hear that the Bertalanffy Discussion Forum
was finally revived by Tom Mandel (hi Tom, it is nice to know that you are
around), and that with a vital and fundamental question. After reading
through all the correspondences, I am once more delighted to say that, this
time, I am very much in agreement with him. Here are my thoughts on the
subject:
"The comments so far are very interesting - as Tom wrote - but hardly form a
consensus", because everybody appears to have a different concept behind the
label. The reason for this are the various synonyms the word "system" has,
like: scheme, organisation, arrangement, classification, structure,
co-ordination, organism, method, technique, procedure, and even orderliness
and logic. If all and everything these labels cover are being stuck under
the label "system", than the answer is that all and everything is a system,
and Tom wouldn't have popped the question.
The right approach would rest in Tom's further clarification: "What I had in
mind when I asked the question was the integrative system, the kind where
the elements work together and form from that a new whole. The question is
important when we talk about integrative systems because the new whole is
actually the emergent property of the relationships." Just as right is James
Rose by stating that "GST addresses deeper principles and ideas - it
challenges the methods of analysis themselves and how people think and
assess what they encounter." - I will follow these lines of thoughts,
because they coincide with my ideas.
Ever since the proton, neutron and electron - the three stable fundamental
particles of all material manifestation - ceased to be "hard little balls"
and became swirling energy-bundles of ordered processes in interwoven and
interdependent harmonic system-relationships of energy-quantums; and the
various intertwining and spinning processes of their harmonious interactions
are forming the hundred or so stable elements; which, in turn, can
constitute, according to their valency, innumerable chemical substances,
stable molecules, "things" also ceased to be "things", and became
harmonious, rational and productive "processes": dynamic systems of various
orders of complexity.
The above chain of systems continues, in growing order of complexity,
through macromolecules of aminoacids, organelles, cells, tissues, organs,
germinal-organ-systems, organisms, ecological communities, planetary
life-complex. Above the two directional linear interaction of the members of
this chain, there exists also the perpendicular interaction of each member
with those on its own level, rendering the planetary life-system to be a
spatial concept.
I must stress the attribute "harmonious", because harmony is a fundamental
factor in all constructive manifestation (as is "cacophony", its
antagonistic opposite, a destructive, degenerative one); and is thus a
foundation principle of the Universe. It produces monistic relationship - or
inversely, monistic relationship represents harmony.
I must also stress the attribute "rational", because ad-hoc events cannot
enter into and be parts of a harmonious relationship and cooperation.
And I must also stress "productive", as the necessary attribute of both the
individual constituents, and of the new system of higher complexity they
constitute.
Consequently, the concept 'system' - within the limits of the General System
Research and Theory - should represent the harmonious, rational and
productive interaction of constituting elements, forming, through these
properties, a complete unit, that becomes thus more than the sum of its
constituting elements, and that cannot be reduced to, or derived at through
the analysis of any of its constituents.
The reducibility principle comes from what I must call a belief, that a
system originates through the interaction of two or more material elements,
and is the derivative of the qualities inherent in these constituting
material elements, which themselves cause the interaction; and that, through
their analysis, the whole system can be known and synthesised. In turn, this
principle is based on the belief that the new system becomes, through the
original interaction, just another "thing" but of higher complexity than are
its constituting "things".
The "interaction" of the constituting elements does not represent the
triggering off the "being" of a new system of higher complexity, but is a
sine qua non constituent of the new system in form of its incessant process
of "becoming", the cessation of which process would result in the immediate
disintegration of the system into its constituting elements. Thus, the
"interaction" itself is as much a constituting element of the derivative
system, as are all the "material" ones, even if it is of non-material
nature.
That the "interaction" itself is not of material nature, and that neither is
it inherent in any of the constituting elements, I will illustrate with the
simple example of water:
If a container is filled with a mixture of oxygen and hydrogen, the oxygen,
being the heavier, will settle in the lower part, and the two gases will
stay in that state side by side till doomsday, without ever changing their
identity. Never will they turn themselves into water, or into
hydrogen-hyperoxide, through an inherent, self-induced process. By
introducing a spark or high pressure into this mixture, the consequent
explosion will end up by joining two hydrogen and one oxygen atoms, to be
held together by relatively strong (valence) forces, which compound, in
consequence, will act as water molecules with completely different physical
and chemical identity and distinctively new character, without any reference
to that of any of its parts, which become unrecognisable in the new complex.
This new "identity" manifests the underlying "mind-stuff", that transcends
the constituting elements and is inherent in the derivative system.
At the first stratum of the Natural Order, where materialisations happen,
where elementary matter (proton, neutron and electron) appear, formed out of
electromagnetic energy-quantums by their particular ordering principles (the
inferred, but unexplained 'virtual particles' of nuclear physics) into
swirling energy-bundles of ordered processes (and where they can also
disintegrate, leaving behind electromagnetic radiation), there exist only
two constituents "interacting" to form the systems of elementary particles:
free energy-quantums and their ordering principles that are not of material
nature.
The further consideration that these ordered processes, consisting of energy
and mind-stuff, are constituting the atoms of all the elements according to
their particular ordering principles of the second order; and that a same
kind of systematic procedure continues towards ever increasing complexities,
brings to the conclusion, that free energy and differentiated underlying
principle are the two common denominators of all the material
manifestations; and that matter, in all its forms, is a structured process
complex of by the mind ordered energy-fields at all levels of its
manifestation, and that the Universe - as any part of it - is formed by
order imposed over a primordial energy-soup by the Ordering Principle which
pervades it. This idea, or rather knowledge, is expressed concisely by the
Nobel laureate biologist George Wald of Harvard: "The stuff of the universe
is mind stuff."
The planetary life-complex includes each and all of its constituents in
systemic co-existence, from the elementary particles upwards. It is
self-configuring and self-sustaining, being dependent only on the
energy-source of the Sun.
For a system to function harmoniously, rationally and productively, its
underlying principle, that animates the constituent parts into a system of
higher complexity, must possess these qualities. I would go even further to
state that a functional, natural system is alive at its own level of
existence, due to its underlying mind-stuff being alive, conscious and
intelligent at the level of its manifestation.
I suggest that from a universal point of view, an entity is alive if it
partakes - at the level of its own being - as a subject, instrument and
originator in the universal life-processes. Von Bertalanffy's and
Woltereck's anamorphosis, i.e., tendency to create new forms of life;
Schrödinger's feeding on negative entropy; Herrick's spontaneously
developing states of greater heterogeneity and complexity; and
Szent-Györgyi's syntropy, that is, innate drive in living matter to perfect
itself, are clear manifestations of the will to live and the will to evolve.
Considering that, summarised: each system represents more than the sum of
its parts; each system is constituted of systems of a lower order and its
ordering principle; each system is an integral constituent of a system of a
higher order; and that none of the systems can be reduced to any of its
constituent parts; - a "system" is, in fact a holistic order, where the
label "system" can be exchange with the label "holon" without altering
anything on the general concept.
The Universe itself is a self-configuring system, where macrocosmic and
microcosmic self-configurations are co-emergent and interdependent, and
represent thus one self-evolving and self-maintaining system. While the
evolution starts on the one extreme with the formation of elementary
particles out of electromagnetic energy, the macrocosmic starts with the
spatial distribution and ordering of these same elementary particles,
developing the double helix by starting simultaneously from both extremes.
Thought, logic and creativity are as intrinsic in the microcosmic existence
as in the macrocosmic one. Microcosmic logic and creativity is producing and
is constantly juggling and reshuffling all the fundamental and ephemeral
subatomic particles, without ever leaving any of it to chance, providing
dependable building blocks, basic rules and ordered energy supplies for a
universe with infinite varieties of form and action. Macrocosmic logic and
creativity maintains and recreates space-time - the thought-form defining
inertial behaviour of matter -, every instant altering its curvature
according to the momentary state of distribution of matter in the universe;
and keeps on manifesting itself in solar and galactic development, dynamic
equilibrium and self-generated and self-sustained metabolic processes, as
those of the whole universe. Within all the ordered turbulence, energy,
coalesces into forms of inorganic and organic matter, composing the
biological structure of living organisms able to support various levels of
higher intelligences, and constituting the crystalline structure of their
underlying ground. This particular reference frame is at the level of the
greatest complexity and diversity within a universal system. It is the
centre of the evolutionary double helix spiralling from the two infinite
extremes: the point towards which syntropy, complexity, diversity increase,
and where local universal evolution culminates: the planetary life-complex.
It is also the centre of the two velocity spirals, from where particular
velocity ranges increase in both directions.
All of it is in harmony with the fundamental chord of the universe.
Everything that we call "nature", and consider as if it would be something
external, something unrelated to us, something that is there for us,
superior human beings, to use and exploit, is existing within this
fundamental harmony. Until all the "real human beings" realise, as their
tribal ancestors did, that all their social, political and economic systems
and all their secular and religious philosophies must be in tune with that
fundamental harmony, there will be "system designers" flourishing on
thinking up exploitive systems and their impressive system models and
mathematical formulas, the social, political and economic disasters and
widespread nihilism will continue within all the existing human cacophony.
I very much realise that the above presented ideas will please extremely few
people, because the materialist credos do not allow "underlying principles"
or "mind-stuff", replacing it with verbs manipulated into acting subjects
(about which I can supply a host of examples both in cosmological and in
evolutionary theories); and the religious credos accept only their
particular dogmas about extrinsic anthropomorph god-images approachable
through the theocratic hierarchy and knee-bent image-supplication or
cross-legged navel-watching. I would be, however, very glad to receive some
rational and constructive arguments.
Imre
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.icts.sbg.ac.at/pipermail/bertalanffy/attachments/20090109/2048e5e1/\
attachment.html
_______________________________________________
Bertalanffy mailing list
Bertalanffy@...http://lists.icts.sbg.ac.at/cgi-bin/mailman/listinfo/bertalanffy
Subject: Re: [objetos] Fin de año y Próxima reunión
Hola muchachos,
No puedo el fin de semana del 17. Me voy el lunes 12 y vuelvo el domingo 18.
Saludos
Elvio
El 10 de enero de 2009 17:25, Angel Java Lopez <ajlopez@...> escribió:
Hola gente!
Leonardo, "el finde" tiene dos dias por mis lares, a cual dia (sabado, domingo) te referias? Entiendo que te referias al sabado, pero no me queda claro.
Subject: RE: [objetos] Fin de año y Próxima reunión
Yo podria recien el finde del 17, si les parece quedamos para ese a las 10hs en....
Opciones??
Saludos, Leo
> -----Mensaje original----- > De: smalltalking@... > [mailto:smalltalking@...] En nombre de Angel > "Java" Lopez > Enviado el: Miércoles, 31 de Diciembre de 2008 07:24 > Para: smalltalking@... > Asunto: Re: [objetos] Fin de año y Próxima reunión > > Hola gente! > > Yo puedo cualquier domingo de Enero (en general, los sabados > estoy dando cursos). > Podria este sabado 3 de Enero. > > Nos leemos! > > Angel "Java" Lopez > http://www.ajlopez.com/ <http://www.ajlopez.com/> > http://twitter.com/ajlopez <http://twitter.com/ajlopez> > > > > ----- Original Message ----- > From: Alejandro F. Reimondo > <mailto:aleReimondo@...> > To: smalltalking@... > <mailto:smalltalking@...> > Sent: Tuesday, December 30, 2008 10:34 AM > Subject: [objetos] Fin de año y Próxima reunión > > > > Estimados, > Estas épocas, de fin de año, me hacen reflexionar sobre > qué cosas he hecho durante el año y cómo me gustaría > arrancar el siguiente. > > > > . > <http://portal.mxlogic.com/images/transparent.gif> > > > > > __________ Información de NOD32, revisión 3724 (20081230) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > >
No puedo el fin de semana del 17. Me voy el lunes 12 y vuelvo el domingo 18.
Saludos
Elvio
El 10 de enero de 2009 17:25, Angel Java Lopez <ajlopez@...> escribió:
Hola gente!
Leonardo, "el finde" tiene dos dias por mis lares, a cual dia (sabado, domingo) te referias? Entiendo que te referias al sabado, pero no me queda claro.
Subject: RE: [objetos] Fin de año y Próxima reunión
Yo podria recien el finde del 17, si les parece quedamos para ese a las 10hs en....
Opciones??
Saludos, Leo
> -----Mensaje original----- > De: smalltalking@... > [mailto:smalltalking@...] En nombre de Angel > "Java" Lopez > Enviado el: Miércoles, 31 de Diciembre de 2008 07:24 > Para: smalltalking@... > Asunto: Re: [objetos] Fin de año y Próxima reunión > > Hola gente! > > Yo puedo cualquier domingo de Enero (en general, los sabados > estoy dando cursos). > Podria este sabado 3 de Enero. > > Nos leemos! > > Angel "Java" Lopez > http://www.ajlopez.com/ <http://www.ajlopez.com/> > http://twitter.com/ajlopez <http://twitter.com/ajlopez> > > > > ----- Original Message ----- > From: Alejandro F. Reimondo > <mailto:aleReimondo@...> > To: smalltalking@... > <mailto:smalltalking@...> > Sent: Tuesday, December 30, 2008 10:34 AM > Subject: [objetos] Fin de año y Próxima reunión > > > > Estimados, > Estas épocas, de fin de año, me hacen reflexionar sobre > qué cosas he hecho durante el año y cómo me gustaría > arrancar el siguiente. > > > > . > <http://portal.mxlogic.com/images/transparent.gif> > > > > > __________ Información de NOD32, revisión 3724 (20081230) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > >
Leonardo, "el finde" tiene dos dias por mis lares, a cual dia (sabado, domingo) te referias? Entiendo que te referias al sabado, pero no me queda claro.
Hola kiko,
>Gracias, se que estas ocupado y no te hagas drama.
jajaja! bienvenido el Sábado! releí un poco tus emails
y creo que puedo darte algunas ideas mas...
Igualmente, es muy dificil ayudar viendo código fuente;
y no pudiendo hacer un doIt.
Es tan dificil/caro ayudar así como producir usando
un lenguaje sin compilar.
>Ya me inscribí a lista de VS y mande una consulta.
Fijate también en la lista histórica,
http://www.listserv.dfn.de/archives/vswe-l.html
>Tambien pregunte en el foro de Jet3d http://apps.sourcefor
>ge.net/phpbb/jetpp/viewtopic.php?f=6&t=19&sid
>=5e782bf5b72568e4922a9b4bc32428ff por si alguien quiere mirar
>No es mucha la ayuda insiste en decirme que no apollan smalltalk. jjaja
Si, en muchos lugares solo apoyan el uso de herramientas de bajo nivel.
Es triste que además las usen para resolver aplicaciones... la percepción
de costos de producción y el éxito son siempre subjetivos.
>Pero seguramente debe haber mas gente trabajando en Vs en la lista ??.
A que lista te referís?
Creo que pocas personas podrán ayudarte leyendo el mail...
Es mas facil encontrar una escusa (por ejemplo que es smalltalk,
o que es visual smalltalk, etc) y protejer el ego :-)
>Seguramente es por las vacaciones que no hay nadie
jajaja! por las vacaciones?
yo diría que es por el frio! creo que la mayoría de la gente
que podría ayudarte está bajo nieve en estos días...
y quizás sin gas.
Bueno, volviendo a lo técnico....
Veo que tenes definida en la librería:
>JETAPI const jeVec3d * JETCC jeBrush_FaceGetVertByIndex(const jeBrush_Face
>*Face, int32 Index)
>{...}
Y que en Smalltalk tenes:
>JetDLL>>jeBrushFaceGetVertByIndex: pJetBrushFace index: pIndex
> <api: '_jeBrush_FaceGetVertByIndex@8' ulong ulong ulongReturn>
> ^self invalidArgument
Para entender qué define la función en C es necesario saber cómo estan
definidas las macros JETAPI, JETCCC que son parte de la parafernalia
que se requiere para hacer algo "decorosamente" en Cpuspus.
(Se que las pasaste por mail... lo digo para que estes seguro de que es
lo que definen.. y que es <api: lo que corresponde)
Pero MAS IMPORTANTE AÚN es necesario saber
dónde está definida la función!!!
Según sospecho esta definida en una clase C++ y eso NO es una fución C!!!
Sospecho que el problema puede ser que la funcion que estas usando es una
funcion (C++) de una clase y por eso esta mangleada.
De ser así, podrías jakearlo del lado del smalltalk agregando un (primer)
parámetro, que sería el receptor del "mensaje" (mensaje que nunca se
envía en C++)...
NO te recomiendo hacerlo de esa forma (auqneu así seguramente te exlicarás
el porque los argumentos son basura... estan desplazados :-) porque
además debes fijarte si es correcto definir los métodos como <api: o <c:
...
etc...
Si la función que estas usando fuera una función C no debería estar
mangleada,
es decir, si esta definida como jeBrush_FaceGetVertByIndex(..)
el literal a usar en smalltalk DEBE ser 'jeBrush_FaceGetVertByIndex'
Para verificar esto hace lo siguiente:
1.- asegurate de tener en el path bien instaladas las herramientas de
cpuspus
y compila nuevamente la DLL.
2.- hace un dump de la dll generada en un archivo de texto con algo asi:
--------------dumpDLL.bat----------------------
c:
cd \ARCHIV~1\MICROS~2\VC98\BIN\
set
PATH=D:\ARCHIV~1\MICROS~2\COMMON\MSDEV98\BIN;D:\ARCHIV~1\MICROS~2\VC98\BIN;D:\AR\
CHIV~1\MICROS~2\COMMON\TOOLS\WIN95;D:\ARCHIV~1\MICROS~2\COMMON\TOOLS;%PATH%
DUMPBIN /exports d:\Jet3D\Smalltalk\miDLL.dll >d:\Jet3D\Smalltalk\miDLL.TXT
--------------------------------------------------
3.- en el TXT fijate las funciones que estan exportadas, a modo de ejemplo
te copio un pedazo de un txt de otro proyecto, pero que creo te servirá por
analogía:
--------------------------------------------------
Microsoft (R) COFF Binary File Dumper Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file d:\OpenCV1\Smalltalk\cv100d.dll
File Type: DLL
Section contains the following exports for cv100d.dll
............................................
461 number of functions
461 number of names
ordinal hint RVA name
1 0 000CC270 ??0CvBaseImageFilter@@QAE@ABV0@@Z
...........................................................
165 A4 000CBE10 ?type@CvMatrix@@QBEHXZ
166 A5 000CAEA0 ?width@CvImage@@QBEHXZ
167 A6 00039111 cv2DRotationMatrix
168 A7 000C2853 cvAcc
...................................................................
457 1C8 000C9516 stcvThreshold
458 1C9 000C9185 stcvUpdateMotionHistory
459 1CA 000C9BE7 stcvWarpAffine
460 1CB 000C9C1E stcvWarpPerspective
461 1CC 000C9B50 stcvXorS
Summary
31000 .data
8000 .rdata
6000 .reloc
1000 .rsrc
CD000 .text
--------------------------------------------------
4.- fijate que las funciones de arriba están mangleadas, son
exportadas porque el binding de runtime de C++ las necesita;
ero no son las que deberías usar.
Adeás de tenes exportadas funciones mangleadas, debes tener
exportadas funciones C stabdard, sin manglear (sin caracteres ? _ ni @)
5.- si no es así, debes escribir (es recomendable que lo hagas)
en C funciones wrappers para exponar la API de la libreria en C.
Normalmente es una tarea muy simple en C y.... si no la hace el que
escribe la librería es porque no quiere hacerlo (no quiere exponer
la funcionalidad de una forma standard y abierta), como creo que
es el caso de Jet3D (fijate que es lo que estan diciendote...
yo creo que deberías escupirlos y decirles que vas a usar otra librería,
sino van a seguri pensando que estan haciendo algo abierto, por el solo
hecho de publicar los fuentes).
Volviendo a lo práctico...
un afunción C++ no te serviría salvo que quieras jakearla, para eso
deberías definir, como te decía, un primer argumento (que es el
componente Cpuspus, el "this") de forma explisita, pues ese argumentos
esta implisito en el lenguaje C++.
Además deberías crear un objeto (que seguro ya lo tenes) del lado de
smalltalk
que tenga ese puntero y además necesitas uan forma de instanciarlo...
Para instanciar dicho objeto puede ocurrir que:
1.- tengas una funcion ya escrita en la librería que devuelva un puntero
a dicha instancia (te devuelvela dirección del componente y eso es lo que
guardas en tu objeto smalltalk, pasandolo luego como "self asParameter"
como ese argumento que te falta)
2.- tengas que hacerte en la librería una funcion C que devuelva
una nueva instancia.
OOPPPPPSSS!!!
ahora, leyendo nuevamente tu email, veo que estas usandola de
la forma que note recomendaba :-)
ok.. entonces tené cuidado porque apenas algo este "medio mal"
te va a explotar todo :-)
Releyendo... vos decias....
>Esta es una función de Jet3D
>JETAPI const jeVec3d * JETCC jeBrush_FaceGetVertByIndex
> (const jeBrush_Face *Face, int32 Index)
....
>JetDLL>>jeBrushFaceGetVertByIndex: pJetBrushFace index: pIndex
> <api: '_jeBrush_FaceGetVertByIndex@8' ulong ulong ulongReturn>
....
>OK
....
>JetDLL>>jeBrushFaceSetVertByIndex: pJetBrushFace index: pIndex vertex:
>pJetVertex
> <api: '_jeBrush_FaceSetVertByIndex@12' ulong ulong struct none>
....
>Ocurre que en la DLL el valor de vertex es basura !!!!!!!!!!!!!!.
>Ahora si yo modifico el tipo de parametro de STRUCT a ULONG
> el valor es correcto !!!!!!!!!!!!!.
Omitiste colocar la definicion en Cpuspus de la función SetVertByIndex...
(o yo no la encontré... asumo que el argumento pJetVertex es un puntero a un
vertex)
>Pero el tipo debería ser un STRUCT pues es un SelfDefinedStructure
>!!!!!!!!!!.
No. El argumento es un puntero, luego debe ser
definido como un ulong (el puntero es lo que pasas,
no toda la estructura... que copiaría su contenido a otro lado)
>De otra manera si yo instanciara desde ST un JetVertex, al intentar
> pasarlo a la DLL me diría que espera un ULONG !!!!!!!!!!.
Cuando te dice que espera un argumento definido de otra forma es
que fallo la api porque los objetos que entraron en los argumentos
no conforman la definición del método API, aún no salió de smalltalk...
Es independiente de cómo sea la función en C en la librería.
Si llega del lado de C mal, puede explotar pero no se chequea nada...
>Que tiene que ver el tipo de retorno CONST en la función ?.
Creo que nada (no deberías estar accediendo via Cpuspus
sino via una API expuesta en C)
>Puede ser un problema para ST que se declare así es tipo de retorno ???.
jajaja... el problema podía ser si "no retorna" jajaja
>Puede ser un bug en la VM de ST ?.
No. Creo que es mal entendimiento de parte tuyo de cómo definir
una API en el caso que se te presenta ahora (que es un hacking
y no un acceso a una funcion C standard)
Lo seguro y decoroso es que quien hace la libreria haga su
trabajo como corresponda y exponga una interfaz standard.
Si no lo hace... yo no montaría mis esarrollos usando la librería
o pagaría el precio de escribir la interfáz (agregando funciones
estupidas del lado de C, como lo hace la gente que "trabaja
bien" en esas herramientas).
>O por el contrario es un comportamiento habitual ?.
Es habitual que uno se equivoque en situaciones de hacking;
pero cuando le encontrás la vuelta luego siempre anda...
es la unica ventaja de lo que "no puede cambiar" :-P
>Se entiende el dilema ? jajaj
suerte! espero te sirva mi larrrrrgo email
Ale.
No es mucha la ayuda insiste en decirme que no apollan smalltalk. jjaja
Pero seguramente debe haber mas gente trabajando en Vs en la lista ??.
Seguramente es por las vacaciones que no hay nadie
saludos kiko
--- El vie 9-ene-09, Alejandro F. Reimondo <aleReimondo@...> escribió:
De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: viernes, 9 de enero de 2009, 10:21 am

kiko,
Leí por arriba lo que mandaste, tengo paciencia, pero no tiempo
como para leerlo todo; creo que no estas entendiendo
bien como se definen los tipos de los métodos api,
lee bien la documentación en el help (creo que allí esta
bien detallada); tambien hay algunas referencias en mails
de la lista de Visual Smalltalk.
No he encontrado errores en la VM de VS en lo que respecta
al manejo de los argumentos, en cambio, si he encontrado
casos dónde no es facil entender cómo definirlos correctamente.
vertex:=brushFace at:0.(suponiendo que ya obtuve la cara).
brushFace at:1 put: vertex.
Ocurre que en la DLL el valor de vertex es basura !!!!!!!!!!!! !!.
Ahora si yo modifico el tipo de parametro de STRUCT a ULONG el valor es correcto !!!!!!!!!!!! !.
Pero el tipo debería ser un STRUCT pues es un SelfDefinedStructur e !!!!!!!!!!.
De otra manera si yo instanciara desde ST un JetVertex, al intentar pasarlo a la DLL me diría que espera un ULONG !!!!!!!!!!.
Esto ocurre modifique o no el vertex obtenido !!!!!!!
Que tiene que ver el tipo de retorno CONST en la función ?.
Puede ser un problema para ST que se declare así es tipo de retorno ???.
Puede ser un bug en la VM de ST ?.
O por el contrario es un comportamiento habitual ?.
Se entiende el dilema ? jajaj
saludos kiko
--- El mié 7-ene-09, Alejandro F. Reimondo <aleReimondo@ smalltalking. net> escribió:
De: Alejandro F. Reimondo <aleReimondo@ smalltalking. net> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: miércoles, 7 de enero de 2009, 9:04 pm

kiko,
Asegurate de estar usando la DLL que compilaste (que debe ser compilada en modo debug).
Como recomendación práctica te diría que elimines toda copia vieja de las DLLs de la librería, luego la compiles y recién allí debugees entrando a Smalltalk...
Una causa de tu problema, creo que puede ser que estas cargando una version distinta de DLL.
Como ven solo invertí los argumentos. Y que paso, algo mas loco aun.
Si mando los argumentos en el orden correcto desde ST ocurre lo mismo que en el primer caso.
Excepto que Index toma el valor de Face tambien !!!!!!!!.
Si mando los argumentos invertidos desde ST, en la DLL vienen en orden correcto!!!! !!.
(Ver captura C++Watch2)
Pero al intentar ejecutar esto:
Vert = *jeVertArray_ GetVertByIndex( Face->Brush->VertArray, Face->Poly->Verts[Index] );
Ocurre esto:
Microsoft Visual Studio
No symbols are loaded for any call stack frame. The source code cannot be displayed.
Luego sale a ST y se habre el debug con esto(Ver captura STDebug)
Estoy completamente confundido y no tengo ni idea de lo que puede pasar.
El tema es que tampoco sé si es un problema de ST o de C++
Alguna idea ??.
Pensaba si tendría que ver con algo que comento Ale sobre Excepciones.
Donde decía que el las usaba cuando sospechaba que la DLL había modificado algun Flag del coprocesador matemático.
Nosé es lo único que se me ocurre.
Como me doy cuenta si esto esta ocurriendo ?
Alguna forma de rastrear lo que pasa a nivel assembler con los argumentos ?.
saludos kiko
--- El mié 7-ene-09, kikoGregoris <kikogregoris@ yahoo.com. ar> escribió:
De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: miércoles, 7 de enero de 2009, 9:04 am
Hola Gente
Bueno estoy con un problema con las llamadas a funciones de Jet3D.
El tema es que segun la forma de obtener un estructura desde la DLL, ocurre que al pasarla nuevamente a la DLL se produce un error muy extraño. La estructura toma valores incorrector dentro de la DLL!!!!!!!!.
Tratando de aclarar paso a mostrar las variantes, que andan y que no andan.
const jeVec3d * JETCC jeVertArray_ GetVertByIndex(const jeVertArray *VArray, jeVertArray_ Index Index) y el método #jeVertArraySetVert ByIndex declara el argumento como un ULONG, luego el VECTOR en el lado de la DLL es CORRECTO !!!!!!!!.
Pero si lo declaro como STRUCT, no me permite mandarlo por que son tipos incompatibles( Espera un ULONG)
El tema es que debería implementar mis propias funciones en la DLL para evitar los inconvenientes, no es que no quiera hacerlo, pero me gustaria mucho saber:
Cual es el problema?. De quien es el problema ? Vs o C++ ?.
vertex:=brushFace at:0.(suponiendo que ya obtuve la cara).
brushFace at:1 put: vertex.
Ocurre que en la DLL el valor de vertex es basura !!!!!!!!!!!!!!.
Ahora si yo modifico el tipo de parametro de STRUCT a ULONG el valor es correcto !!!!!!!!!!!!!.
Pero el tipo debería ser un STRUCT pues es un SelfDefinedStructure !!!!!!!!!!.
De otra manera si yo instanciara desde ST un JetVertex, al intentar pasarlo a la DLL me diría que espera un ULONG !!!!!!!!!!.
Esto ocurre modifique o no el vertex obtenido !!!!!!!
Que tiene que ver el tipo de retorno CONST en la función ?.
Puede ser un problema para ST que se declare así es tipo de retorno ???.
Puede ser un bug en la VM de ST ?.
O por el contrario es un comportamiento habitual ?.
Se entiende el dilema ? jajaj
saludos kiko
--- El mié 7-ene-09, Alejandro F. Reimondo <aleReimondo@...> escribió:
De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: miércoles, 7 de enero de 2009, 9:04 pm

kiko,
Asegurate de estar usando la DLL que compilaste (que debe ser compilada en modo debug).
Como recomendación práctica te diría que elimines toda copia vieja de las DLLs de la librería, luego la compiles y recién allí debugees entrando a Smalltalk...
Una causa de tu problema, creo que puede ser que estas cargando una version distinta de DLL.
Como ven solo invertí los argumentos. Y que paso, algo mas loco aun.
Si mando los argumentos en el orden correcto desde ST ocurre lo mismo que en el primer caso.
Excepto que Index toma el valor de Face tambien !!!!!!!!.
Si mando los argumentos invertidos desde ST, en la DLL vienen en orden correcto!!!! !!.
(Ver captura C++Watch2)
Pero al intentar ejecutar esto:
Vert = *jeVertArray_ GetVertByIndex( Face->Brush->VertArray, Face->Poly->Verts[Index] );
Ocurre esto:
Microsoft Visual Studio
No symbols are loaded for any call stack frame. The source code cannot be displayed.
Luego sale a ST y se habre el debug con esto(Ver captura STDebug)
Estoy completamente confundido y no tengo ni idea de lo que puede pasar.
El tema es que tampoco sé si es un problema de ST o de C++
Alguna idea ??.
Pensaba si tendría que ver con algo que comento Ale sobre Excepciones.
Donde decía que el las usaba cuando sospechaba que la DLL había modificado algun Flag del coprocesador matemático.
Nosé es lo único que se me ocurre.
Como me doy cuenta si esto esta ocurriendo ?
Alguna forma de rastrear lo que pasa a nivel assembler con los argumentos ?.
saludos kiko
--- El mié 7-ene-09, kikoGregoris <kikogregoris@ yahoo.com. ar> escribió:
De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: miércoles, 7 de enero de 2009, 9:04 am
Hola Gente
Bueno estoy con un problema con las llamadas a funciones de Jet3D.
El tema es que segun la forma de obtener un estructura desde la DLL, ocurre que al pasarla nuevamente a la DLL se produce un error muy extraño. La estructura toma valores incorrector dentro de la DLL!!!!!!!!.
Tratando de aclarar paso a mostrar las variantes, que andan y que no andan.
const jeVec3d * JETCC jeVertArray_ GetVertByIndex(const jeVertArray *VArray, jeVertArray_ Index Index) y el método #jeVertArraySetVert ByIndex declara el argumento como un ULONG, luego el VECTOR en el lado de la DLL es CORRECTO !!!!!!!!.
Pero si lo declaro como STRUCT, no me permite mandarlo por que son tipos incompatibles( Espera un ULONG)
El tema es que debería implementar mis propias funciones en la DLL para evitar los inconvenientes, no es que no quiera hacerlo, pero me gustaria mucho saber:
Cual es el problema?. De quien es el problema ? Vs o C++ ?.
vertex:=brushFace at:0.(suponiendo que ya obtuve la cara).
brushFace at:1 put: vertex.
Ocurre que en la DLL el valor de vertex es basura !!!!!!!!!!!!!!.
Ahora si yo modifico el tipo de parametro de STRUCT a ULONG el valor es correcto !!!!!!!!!!!!!.
Pero el tipo debería ser un STRUCT pues es un SelfDefinedStructure !!!!!!!!!!.
De otra manera si yo instanciara desde ST un JetVertex, al intentar pasarlo a la DLL me diría que espera un ULONG !!!!!!!!!!.
Esto ocurre modifique o no el vertex obtenido !!!!!!!
Que tiene que ver el tipo de retorno CONST en la función ?.
Puede ser un problema para ST que se declare así es tipo de retorno ???.
Puede ser un bug en la VM de ST ?.
O por el contrario es un comportamiento habitual ?.
Se entiende el dilema ? jajaj
saludos kiko
--- El mié 7-ene-09, Alejandro F. Reimondo <aleReimondo@...> escribió:
De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: miércoles, 7 de enero de 2009, 9:04 pm

kiko,
Asegurate de estar usando la DLL que compilaste (que debe ser compilada en modo debug).
Como recomendación práctica te diría que elimines toda copia vieja de las DLLs de la librería, luego la compiles y recién allí debugees entrando a Smalltalk...
Una causa de tu problema, creo que puede ser que estas cargando una version distinta de DLL.
Como ven solo invertí los argumentos. Y que paso, algo mas loco aun.
Si mando los argumentos en el orden correcto desde ST ocurre lo mismo que en el primer caso.
Excepto que Index toma el valor de Face tambien !!!!!!!!.
Si mando los argumentos invertidos desde ST, en la DLL vienen en orden correcto!!!! !!.
(Ver captura C++Watch2)
Pero al intentar ejecutar esto:
Vert = *jeVertArray_ GetVertByIndex( Face->Brush->VertArray, Face->Poly->Verts[Index] );
Ocurre esto:
Microsoft Visual Studio
No symbols are loaded for any call stack frame. The source code cannot be displayed.
Luego sale a ST y se habre el debug con esto(Ver captura STDebug)
Estoy completamente confundido y no tengo ni idea de lo que puede pasar.
El tema es que tampoco sé si es un problema de ST o de C++
Alguna idea ??.
Pensaba si tendría que ver con algo que comento Ale sobre Excepciones.
Donde decía que el las usaba cuando sospechaba que la DLL había modificado algun Flag del coprocesador matemático.
Nosé es lo único que se me ocurre.
Como me doy cuenta si esto esta ocurriendo ?
Alguna forma de rastrear lo que pasa a nivel assembler con los argumentos ?.
saludos kiko
--- El mié 7-ene-09, kikoGregoris <kikogregoris@ yahoo.com. ar> escribió:
De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: miércoles, 7 de enero de 2009, 9:04 am
Hola Gente
Bueno estoy con un problema con las llamadas a funciones de Jet3D.
El tema es que segun la forma de obtener un estructura desde la DLL, ocurre que al pasarla nuevamente a la DLL se produce un error muy extraño. La estructura toma valores incorrector dentro de la DLL!!!!!!!!.
Tratando de aclarar paso a mostrar las variantes, que andan y que no andan.
const jeVec3d * JETCC jeVertArray_ GetVertByIndex(const jeVertArray *VArray, jeVertArray_ Index Index) y el método #jeVertArraySetVert ByIndex declara el argumento como un ULONG, luego el VECTOR en el lado de la DLL es CORRECTO !!!!!!!!.
Pero si lo declaro como STRUCT, no me permite mandarlo por que son tipos incompatibles( Espera un ULONG)
El tema es que debería implementar mis propias funciones en la DLL para evitar los inconvenientes, no es que no quiera hacerlo, pero me gustaria mucho saber:
Cual es el problema?. De quien es el problema ? Vs o C++ ?.
Asegurate de estar usando la DLL que compilaste (que debe ser compilada en modo debug).
Como recomendación práctica te diría que elimines toda copia vieja de las DLLs de la librería, luego la compiles y recién allí debugees entrando a Smalltalk...
Una causa de tu problema, creo que puede ser que estas cargando una version distinta de DLL.
Como ven solo invertí los argumentos. Y que paso, algo mas loco aun.
Si mando los argumentos en el orden correcto desde ST ocurre lo mismo que en el primer caso.
Excepto que Index toma el valor de Face tambien !!!!!!!!.
Si mando los argumentos invertidos desde ST, en la DLL vienen en orden correcto!!!!!!.
(Ver captura C++Watch2)
Pero al intentar ejecutar esto:
Vert = *jeVertArray_GetVertByIndex(Face->Brush->VertArray, Face->Poly->Verts[Index]);
Ocurre esto:
Microsoft Visual Studio
No symbols are loaded for any call stack frame. The source code cannot be displayed.
Luego sale a ST y se habre el debug con esto(Ver captura STDebug)
Estoy completamente confundido y no tengo ni idea de lo que puede pasar.
El tema es que tampoco sé si es un problema de ST o de C++
Alguna idea ??.
Pensaba si tendría que ver con algo que comento Ale sobre Excepciones.
Donde decía que el las usaba cuando sospechaba que la DLL había modificado algun Flag del coprocesador matemático.
Nosé es lo único que se me ocurre.
Como me doy cuenta si esto esta ocurriendo ?
Alguna forma de rastrear lo que pasa a nivel assembler con los argumentos ?.
saludos kiko
--- El mié 7-ene-09, kikoGregoris <kikogregoris@...> escribió:
De: kikoGregoris <kikogregoris@...> Asunto: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: miércoles, 7 de enero de 2009, 9:04 am
Hola Gente
Bueno estoy con un problema con las llamadas a funciones de Jet3D.
El tema es que segun la forma de obtener un estructura desde la DLL, ocurre que al pasarla nuevamente a la DLL se produce un error muy extraño. La estructura toma valores incorrector dentro de la DLL!!!!!!!!.
Tratando de aclarar paso a mostrar las variantes, que andan y que no andan.
const jeVec3d * JETCC jeVertArray_ GetVertByIndex(const jeVertArray *VArray, jeVertArray_ Index Index) y el método #jeVertArraySetVert ByIndex declara el argumento como un ULONG, luego el VECTOR en el lado de la DLL es CORRECTO !!!!!!!!.
Pero si lo declaro como STRUCT, no me permite mandarlo por que son tipos incompatibles( Espera un ULONG)
El tema es que debería implementar mis propias funciones en la DLL para evitar los inconvenientes, no es que no quiera hacerlo, pero me gustaria mucho saber:
Cual es el problema?. De quien es el problema ? Vs o C++ ?.
Subject: [objetos] VS: Pasando structuras a una DLL
Hola Gente
Bueno estoy con un problema con las llamadas a funciones de Jet3D.
El tema es que segun la forma de obtener un estructura desde la DLL, ocurre que al pasarla nuevamente a la DLL se produce un error muy extraño. La estructura toma valores incorrector dentro de la DLL!!!!!!!!.
Tratando de aclarar paso a mostrar las variantes, que andan y que no andan.
const jeVec3d * JETCC jeVertArray_GetVertByIndex(const jeVertArray *VArray, jeVertArray_Index Index) y el método #jeVertArraySetVertByIndex declara el argumento como un ULONG, luego el VECTOR en el lado de la DLL es CORRECTO !!!!!!!!.
Pero si lo declaro como STRUCT, no me permite mandarlo por que son tipos incompatibles(Espera un ULONG)
El tema es que debería implementar mis propias funciones en la DLL para evitar los inconvenientes, no es que no quiera hacerlo, pero me gustaria mucho saber:
Cual es el problema?. De quien es el problema ? Vs o C++ ?.
Cual es la solución correcta ?
Bueno, espero no abrumar con esto.
saludos kiko
Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer.yahoo.com/cocina/
--- El mié 7-ene-09, kikoGregoris <kikogregoris@...> escribió:
De: kikoGregoris <kikogregoris@...> Asunto: Re: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: miércoles, 7 de enero de 2009, 4:46 pm
Hola Gente
Definitivamente hay algo que no anda bien.Esto es realmente extraño.
Cuando llamo a una función desde ST los argumentos dentro de la DLL llegan a la inversa o con valores incorrectos! !!!!.
Esto se supone que tiene que ver con la convención que se definió la función en la DLL y la que esta usando el método en ST.
Pero no es así. Porque ? Hay va lo loco.
Esta es la convencion que define Jet3D:
// Krouer - change calling convention to __stdcall
// keep __fastcall for internal call perhaps engine can increase the gain by using __inline instead
// but __inline will increase the size
#define
JETCF __fastcall
#define
JETCC __stdcall
// paradoxnj - We don't care about static libs. Changed to conventional DLL export
#ifdef
JETENGINE_EXPORTS
#define
JETAPI _declspec(dllexport)
#else
#define JETAPI _declspec(dllimport )
#endif
#define
JETLINE __inline //added (cyrius)
Esta es la funcion que retorna un vertice por indice:
Como ven solo invertí los argumentos. Y que paso, algo mas loco aun.
Si mando los argumentos en el orden correcto desde ST ocurre lo mismo que en el primer caso.
Excepto que Index toma el valor de Face tambien !!!!!!!!.
Si mando los argumentos invertidos desde ST, en la DLL vienen en orden correcto!!!! !!.
(Ver captura C++Watch2)
Pero al intentar ejecutar esto:
Vert = *jeVertArray_ GetVertByIndex( Face->Brush->VertArray, Face->Poly->Verts[Index] );
Ocurre esto:
Microsoft Visual Studio
No symbols are loaded for any call stack frame. The source code cannot be displayed.
Luego sale a ST y se habre el debug con esto(Ver captura STDebug)
Estoy completamente confundido y no tengo ni idea de lo que puede pasar.
El tema es que tampoco sé si es un problema de ST o de C++
Alguna idea ??.
Pensaba si tendría que ver con algo que comento Ale sobre Excepciones.
Donde decía que el las usaba cuando sospechaba que la DLL había modificado algun Flag del coprocesador matemático.
Nosé es lo único que se me ocurre.
Como me doy cuenta si esto esta ocurriendo ?
Alguna forma de rastrear lo que pasa a nivel assembler con los argumentos ?.
saludos kiko
--- El mié 7-ene-09, kikoGregoris <kikogregoris@ yahoo.com. ar> escribió:
De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@ gruposyahoo. com.ar Fecha: miércoles, 7 de enero de 2009, 9:04 am
Hola Gente
Bueno estoy con un problema con las llamadas a funciones de Jet3D.
El tema es que segun la forma de obtener un estructura desde la DLL, ocurre que al pasarla nuevamente a la DLL se produce un error muy extraño. La estructura toma valores incorrector dentro de la DLL!!!!!!!!.
Tratando de aclarar paso a mostrar las variantes, que andan y que no andan.
const jeVec3d * JETCC jeVertArray_ GetVertByIndex(const jeVertArray *VArray, jeVertArray_ Index Index) y el método #jeVertArraySetVert ByIndex declara el argumento como un ULONG, luego el VECTOR en el lado de la DLL es CORRECTO !!!!!!!!.
Pero si lo declaro como STRUCT, no me permite mandarlo por que son tipos incompatibles( Espera un ULONG)
El tema es que debería implementar mis propias funciones en la DLL para evitar los inconvenientes, no es que no quiera hacerlo, pero me gustaria mucho saber:
Cual es el problema?. De quien es el problema ? Vs o C++ ?.
Como ven solo invertí los argumentos. Y que paso, algo mas loco aun.
Si mando los argumentos en el orden correcto desde ST ocurre lo mismo que en el primer caso.
Excepto que Index toma el valor de Face tambien !!!!!!!!.
Si mando los argumentos invertidos desde ST, en la DLL vienen en orden correcto!!!!!!.
(Ver captura C++Watch2)
Pero al intentar ejecutar esto:
Vert = *jeVertArray_GetVertByIndex(Face->Brush->VertArray, Face->Poly->Verts[Index]);
Ocurre esto:
Microsoft Visual Studio
No symbols are loaded for any call stack frame. The source code cannot be displayed.
Luego sale a ST y se habre el debug con esto(Ver captura STDebug)
Estoy completamente confundido y no tengo ni idea de lo que puede pasar.
El tema es que tampoco sé si es un problema de ST o de C++
Alguna idea ??.
Pensaba si tendría que ver con algo que comento Ale sobre Excepciones.
Donde decía que el las usaba cuando sospechaba que la DLL había modificado algun Flag del coprocesador matemático.
Nosé es lo único que se me ocurre.
Como me doy cuenta si esto esta ocurriendo ?
Alguna forma de rastrear lo que pasa a nivel assembler con los argumentos ?.
saludos kiko
--- El mié 7-ene-09, kikoGregoris <kikogregoris@...> escribió:
De: kikoGregoris <kikogregoris@...> Asunto: [objetos] VS: Pasando structuras a una DLL Para: smalltalking@... Fecha: miércoles, 7 de enero de 2009, 9:04 am
Hola Gente
Bueno estoy con un problema con las llamadas a funciones de Jet3D.
El tema es que segun la forma de obtener un estructura desde la DLL, ocurre que al pasarla nuevamente a la DLL se produce un error muy extraño. La estructura toma valores incorrector dentro de la DLL!!!!!!!!.
Tratando de aclarar paso a mostrar las variantes, que andan y que no andan.
const jeVec3d * JETCC jeVertArray_ GetVertByIndex(const jeVertArray *VArray, jeVertArray_ Index Index) y el método #jeVertArraySetVert ByIndex declara el argumento como un ULONG, luego el VECTOR en el lado de la DLL es CORRECTO !!!!!!!!.
Pero si lo declaro como STRUCT, no me permite mandarlo por que son tipos incompatibles( Espera un ULONG)
El tema es que debería implementar mis propias funciones en la DLL para evitar los inconvenientes, no es que no quiera hacerlo, pero me gustaria mucho saber:
Cual es el problema?. De quien es el problema ? Vs o C++ ?.
Yo podria recien el finde del 17, si les parece quedamos para ese a las 10hs
en....
Opciones??
Saludos,
Leo
> -----Mensaje original-----
> De: smalltalking@...
> [mailto:smalltalking@...] En nombre de Angel
> "Java" Lopez
> Enviado el: Miércoles, 31 de Diciembre de 2008 07:24
> Para: smalltalking@...
> Asunto: Re: [objetos] Fin de año y Próxima reunión
>
> Hola gente!
>
> Yo puedo cualquier domingo de Enero (en general, los sabados
> estoy dando cursos).
> Podria este sabado 3 de Enero.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com/ <http://www.ajlopez.com/>
> http://twitter.com/ajlopez <http://twitter.com/ajlopez>
>
>
>
> ----- Original Message -----
> From: Alejandro F. Reimondo
> <mailto:aleReimondo@...>
> To: smalltalking@...
> <mailto:smalltalking@...>
> Sent: Tuesday, December 30, 2008 10:34 AM
> Subject: [objetos] Fin de año y Próxima reunión
>
>
>
> Estimados,
> Estas épocas, de fin de año, me hacen reflexionar sobre
> qué cosas he hecho durante el año y cómo me gustaría
> arrancar el siguiente.
>
>
>
> .
> <http://portal.mxlogic.com/images/transparent.gif>
>
>
>
>
> __________ Información de NOD32, revisión 3724 (20081230) __________
>
> Este mensaje ha sido analizado con NOD32 antivirus system
> http://www.nod32.com
>
>
Bueno estoy con un problema con las llamadas a funciones de Jet3D.
El tema es que segun la forma de obtener un estructura desde la DLL, ocurre que al pasarla nuevamente a la DLL se produce un error muy extraño. La estructura toma valores incorrector dentro de la DLL!!!!!!!!.
Tratando de aclarar paso a mostrar las variantes, que andan y que no andan.
const jeVec3d * JETCC jeVertArray_GetVertByIndex(const jeVertArray *VArray, jeVertArray_Index Index) y el método #jeVertArraySetVertByIndex declara el argumento como un ULONG, luego el VECTOR en el lado de la DLL es CORRECTO !!!!!!!!.
Pero si lo declaro como STRUCT, no me permite mandarlo por que son tipos incompatibles(Espera un ULONG)
El tema es que debería implementar mis propias funciones en la DLL para evitar los inconvenientes, no es que no quiera hacerlo, pero me gustaria mucho saber:
Cual es el problema?. De quien es el problema ? Vs o C++ ?.
Cual es la solución correcta ?
Bueno, espero no abrumar con esto.
saludos kiko
Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer.yahoo.com/cocina/
Sin conexión 
Enviar correo
