jscl-meditor-devel Mailing List for jscl-meditor
Brought to you by:
rjolly
Menu
▾
▴
jscl-meditor-devel
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Raphael J. <rap...@fr...> - 2009-05-15 15:09:06
|
jscl-meditor is a java symbolic computing library with a text editor
frontend. Version 3.1 is out, in this release:
* Packages for the following projects are added:
MathPiper - active fork of Yacas
Jasymca - Symbolic Calculator for Java
SymPy - Python library for symbolic mathematics
* Most engines are enabled for java web start and available on-line
from the project web page
* There is a new plotting facility which is used in Hartmath,
MathEclipse and Jasymca (more engines to come). It is based on SVG and
Batik and works as follows : as a "plot" expression is evaluated, it is
converted in SVG and pasted in the editor. The latter renders
automatically any expression enclosed in svg tags, as it already did for
MathML. Exports to PDF and XHTML are supported, in vector graphics
* XML libraries are upgraded to their up-to-date versions, namely:
jeuclid-3.1.4
fop-0.95
batik-1.7
* Version 1.0 of ScAS is made available
* Some other engine upgrades are made:
sympy-0.6.4_beta2
hartmath-08pre2
matheclipse-0.0.7
* Some transverse library interactions are considered : through its
Jython interface, the ScAS library can be used from the JAS engine. The
newly included JLinAlg library can be used from any engine with import
ability (i.e. Jython, BeanShell or Scala based ones, namely : JAS,
SymPy, JSCL, ScAS)
* All engine packages are grouped together with the editor
* The mathematical editor is turned into a general purpose script
editor : the chooser file filter is set to "accept all" (script
extensions, instead of just "txt") and the "math->evaluate" menu item is
changed into "script->run/evaluate". When no selection is made, the
whole script is run.
* The document root of the treepad can be changed
Download the new release at:
http://downloads.sourceforge.net/jscl-meditor/meditor3.1.zip
|
|
From: Raphael J. <rap...@fr...> - 2009-01-18 15:35:09
|
jscl-meditor is a java symbolic computing library with a text editor frontend. From version 3.0 onward, it is possible to substitute several script-based engines to the standard one (JSCL). Today a new engine is available based on the well-known Python-based CAS SymPy, via Jython. Download it from: http://downloads.sourceforge.net/jscl-meditor/meditor3.0-sympy.zip |
|
From: UPM <kla...@ro...> - 2008-12-21 02:00:50
|
Greetings from Under Pressure Music! The link below is UNDER PRESSURE MUSIC'S homepage where you can listen to and free download tons of their newest releases. Fans from all over the world are talking about UNDER PRESSURE MUSIC. Here is what some of their fans had to say : "Too Late is one brilliant song. Love it. My wife loves it. Love the shuffle rhythm, rhythm of the melody, harmonies. Gold!" from: Car 55 Sydney, AU. "Just when you think you know where the song is going, They do a total 360. Very innovative, a breath of fresh air for weary music lovers." Eldon St. Johns NF, CA. "Love the variety of this CD.. You guys are HOT! keep on Rockin' " ADDIE Palo Alto CA, US. Don't miss out on your chance to download all these great tracks for free (but not for long!) at <http://www.reverbnation.com/underpressure> If you like them as much as many of their loyal fans do, sign up to Reverbnation and become a fan of UNDER PRESSURE MUSIC. |
|
From: Raphael J. <rap...@fr...> - 2008-11-05 16:38:01
|
Erik, Pour la racine carrée, en 3.1.3 elle est rendue en traçant des lignes, alors qu'en 3.0.3 c'était un caractère, donc évidemment le bug n'existe plus. Je voulais rester en version 3.0.3 parce que j'espérais pouvoir la retrotranslater, mais comme ce n'est pas le cas, je vais peut-être passer à la 3.1.3 pour les futures versions de meditor. Pour gnu regexp, de quelle version de meditor parles-tu ? la version 2.3_05 n'en dépend pas, regexp est standard en java 1.4. Concernant les attributs de variables, si je comprends, il s'agirait d'ajouter un champ tel que: public Attributes attributes = new DefaultAttributes(); , à la class jscl.math.Generic (la racine de toutes les classes ayant un rendu en MathML), et de modifier la methode toMathML pour tenir compte des attributs. Comme je te disais, de mon côté je ne compte plus trop faire de développements sur jscl, mais si ça te tente, j'ai créé dans CVS: http://jscl-meditor.cvs.sourceforge.net/jscl-meditor/ , un nouveau répertoire "jscl3", avec tout ce qu'il faut pour engendrer le plugin jscl pour meditor3.0. Dans ce répertoire, tu es chez toi, fais-y ce que tu veux ; je t'ai ajouté au projet pour les droits. Mon nouveau projet (ScAS) en ce qui le concerne, sera très différent, je ne sais même pas encore où il sera hébergé. Le rendu MathML n'est pas encore finalisé. Par contre, le fonctionnement sera le suivant : à partir d'un objet mathématique x, on tapera: x.toMathML et on obtiendra une chaine XML, qui sera rendue automatiquement par l'éditeur (meditor3.0 donc). Ce sera donc beaucoup plus souple pour mettre des attributs, mais par contre ce ne sera pas du DOM contrairement au cas de jscl 2.3_05. Pour la licence, la librairie est en LGPL et l'éditeur est en GPL. Raphael Putrycz, Erik wrote: > >> Le bug de la racine carrée en pdf a été corrigé grace à cette >> modification: >> >> http://jeuclid.svn.sourceforge.net/viewvc/jeuclid/branches/3.0/jeuclid- >> core/src/main/java/net/sourceforge/jeuclid/elements/presentation/general/A >> bstractRoot.java?r1=384&r2=736 >> >> Je n'ai plus sous la main de quoi le reproduire, j'ai tourné le dos à ce >> cauchemar. > > Cette classe a été réécrite visiblement et vu le nombre de tests unitaires, je parie que ce bug devrait être réglé. > > En passant, j'ai supprime les dépendances de meditor de GNU regex avec le JDK 1.5. Je pense que, tout au contraire, ce genre de détail facilite l'utilisation de meditor... Le JDK 1.4 est aujourd'hui un peu daté. > > Sinon concernant les attributs et les variables, serais tu favorable a ce genre de modification ? Je veux bien faire un patch mais avant de consacrer un peu de temps pour ca, j'aimerai avoir une idée si ces modifs ont une chance d'être commitees. > Et penses tu pouvoir conserver une API stable même avec du code en Scala? > Ces deux points sont importants pour mon projet actuel, sinon il faut que je considère un autre outil. > > Et dernière question, la licence est-elle GPL ou LGPL? Sourceforge dit LGPL mais il me semble avoir vu qq part GPL aussi. > > Erik. |
|
From: Putrycz, E. <Eri...@nr...> - 2008-11-04 18:13:23
|
> Le bug de la racine carrée en pdf a été corrigé grace à cette > modification: > > http://jeuclid.svn.sourceforge.net/viewvc/jeuclid/branches/3.0/jeuclid- > core/src/main/java/net/sourceforge/jeuclid/elements/presentation/general/A > bstractRoot.java?r1=384&r2=736 > > Je n'ai plus sous la main de quoi le reproduire, j'ai tourné le dos à ce > cauchemar. Cette classe a été réécrite visiblement et vu le nombre de tests unitaires, je parie que ce bug devrait être réglé. En passant, j'ai supprime les dépendances de meditor de GNU regex avec le JDK 1.5. Je pense que, tout au contraire, ce genre de détail facilite l'utilisation de meditor... Le JDK 1.4 est aujourd'hui un peu daté. Sinon concernant les attributs et les variables, serais tu favorable a ce genre de modification ? Je veux bien faire un patch mais avant de consacrer un peu de temps pour ca, j'aimerai avoir une idée si ces modifs ont une chance d'être commitees. Et penses tu pouvoir conserver une API stable même avec du code en Scala? Ces deux points sont importants pour mon projet actuel, sinon il faut que je considère un autre outil. Et dernière question, la licence est-elle GPL ou LGPL? Sourceforge dit LGPL mais il me semble avoir vu qq part GPL aussi. Erik. |
|
From: Raphael J. <rap...@fr...> - 2008-11-04 16:15:53
|
Le bug de la racine carrée en pdf a été corrigé grace à cette modification: http://jeuclid.svn.sourceforge.net/viewvc/jeuclid/branches/3.0/jeuclid-core/src/main/java/net/sourceforge/jeuclid/elements/presentation/general/AbstractRoot.java?r1=384&r2=736 Je n'ai plus sous la main de quoi le reproduire, j'ai tourné le dos à ce cauchemar. Concernant 1.4, c'était entre autres à cause de ceci: JTextPane frozen after selection of a line content+Enter http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=4068ef1189454fffffffff7a3fafbe76f6ea?bug_id=6665820 , mais appremment c'est corrigé: Infinite loop in FlowView.layout when using HTML tables in JEditorPane http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=68429f8d432dd7bfcf98f72d7894?bug_id=6606443 , donc je vais peut-être reconsidérer ma position. Mais encore une fois, comme tout le reste de meditor est compatible, autant essayer de rester dans la version la plus basse, histoire de n'exclure aucun utilisateur ; c'est le principe que je me fixe en tout cas. Raphael Putrycz, Erik wrote: > Il faudrait que tu me donnes un exemple qui cause le bug en pdf. > Sinon pourquoi te soucies tu de la compatibilite JDK 1.4? Toutes les > plateformes (meme - et surtout - open source) sont JDK 1.6 de nos jours. > > Tiens moi au courant pour le reste. > > Erik. > > -----Original Message----- > From: Raphael Jolly [mailto:rap...@fr...] > Sent: Sat 11/1/2008 3:01 PM > To: jsc...@li... > Subject: Re: [Jscl-meditor-devel] contributing to JSCL > > Jeuclid : j'ai eu un gros problème de rendu de racine carré en pdf. > J'utilise la version 3.0.3 avec un patch de mon cru. La dernière fois > que j'ai regardé, aucune version de jeuclid n'était retrotranslatable > vers 1.4, sans parler d'être dans cette version à proprement parler. Je > télécharge les dernières versions et je regarde. > > Pour le reste, il faut que je voie ça au fur et à mesure (je suis un peu > débordé en ce moment). > > Raphael > > Putrycz, Erik wrote: >> Hi Raphael, >> >>> Regarding maven, if I understand it is like >>> ant but more powerful. For the time being ant fulfills my needs, >>> sometimes I even use simple shell scripts to build projects because I >> am >>> moving to scala and I don't know a ant/maven replacement for it. >> >> I converted the project to maven, plus I converted the testcases to >> TestNG (instead of JUnit 3). >> >> There is a maven plugin for scala as well >> (http://scala-tools.org/mvnsites/maven-scala-plugin/). Maven handles >> much more of the app lifecycle than ant does. Maven handles >> documentation, testing, releases and building. I'm not saying that it is >> necessarily easier but when you want to make a release, there is much >> less work involved. >> >> In one command, maven can generate a web site, tag the svn, copy the >> build to a location and publish the artefact on a repository to make it >> available. >> And then it can be distributed on the maven central repository, this >> allows to add jscl to a project in one click. >> Have a look at the current JEuclid web site. >> >>> Regarding a DOM export instead of XML text, I am not sure of what you >>> mean. Currently XML export goes to a file, where is DOM supposed to go >> ? >> >> DOM can go to several outputs; file or it could go directly to another >> framework, JEuclid for instance. This way if you need to integrate >> JEuclid and JSCL, you don't need to go back and forth to XML. Also, on >> the code site, it is much nicer to generate rather than outputting xml. >> >>> What do you mean also with "bind variables to any java object" ? Do >> you >>> have an example ? >> >> Actually my needs are a even more complex... I have my own parser that >> reads formulas from COBOL and I build my own tree for a formula. So I >> will need somehow to use the tree model from JSCL and build manually the >> formulas instead of using your parser. >> And I have plenty of attributes attached to each variable (e.g. color) >> and after a transformation in JSCL, I need to preserve these attributes. >> This would require some simple refactoring that wouldn't break any >> existing functionality. >> >>> Regading MathML, I'm currently researching in quite an opposed >> direction >>> to yours. I was thinking of using pMML2SVG to translate MathML to SVG >>> and then get rid of Jeuclid altogether (I can't retrotranslate it to >>> java 1.4 unlike everything else and such backward compatibility is >>> important to me (It wouldn't be if scala didn't run on 1.4, but it >> does, >>> so java 1.6 is totally redundant here)). >> >> Let me know what issues you encounter, JEuclid should allow to go from >> MathML to many different formats including SVG. I'm not sure what issues >> you mention with JDK 1.4 but the most recent version of JEuclid runs on >> every JDK version. You might be using an old version. The most recent is >> 3.1.0. >> >>> Lastly, I am currently working on a port of jscl (and also/mainly JAS) >>> to (hence) scala, so I am considering to freeze developments on jscl. >>> Among others, the support for boolean algebra will be much better in >> the >>> new project. >> >> This sounds really great. I haven't found much support for Boolean >> algebra in other projects so I might stick with JSCL. Are there any >> chances you can preserve the tree model and parser part? (you shouldn't >> need to redevelop that part in theory since scala is fully interoperable >> with existing Java) I don't mind using JSCL even if it is evolving. >> >>> As as you see, our directions don't quite converge, but if you can >> find >>> something you can work on in what I cited, you are very welcome ! >> >> If there is a way that you can use a stable tree model for the upcoming >> changes in Scala, I would be glad to help. >> >> Et s'il n'y a personne d'autre sur la liste, on peut causer en Francais >> :-) >> >> Bests, >> >> Erik |
|
From: Putrycz, E. <Eri...@nr...> - 2008-11-02 02:41:36
|
Il faudrait que tu me donnes un exemple qui cause le bug en pdf. Sinon pourquoi te soucies tu de la compatibilite JDK 1.4? Toutes les plateformes (meme - et surtout - open source) sont JDK 1.6 de nos jours. Tiens moi au courant pour le reste. Erik. -----Original Message----- From: Raphael Jolly [mailto:rap...@fr...] Sent: Sat 11/1/2008 3:01 PM To: jsc...@li... Subject: Re: [Jscl-meditor-devel] contributing to JSCL Jeuclid : j'ai eu un gros problème de rendu de racine carré en pdf. J'utilise la version 3.0.3 avec un patch de mon cru. La dernière fois que j'ai regardé, aucune version de jeuclid n'était retrotranslatable vers 1.4, sans parler d'être dans cette version à proprement parler. Je télécharge les dernières versions et je regarde. Pour le reste, il faut que je voie ça au fur et à mesure (je suis un peu débordé en ce moment). Raphael Putrycz, Erik wrote: > Hi Raphael, > >> Regarding maven, if I understand it is like >> ant but more powerful. For the time being ant fulfills my needs, >> sometimes I even use simple shell scripts to build projects because I > am >> moving to scala and I don't know a ant/maven replacement for it. > > I converted the project to maven, plus I converted the testcases to > TestNG (instead of JUnit 3). > > There is a maven plugin for scala as well > (http://scala-tools.org/mvnsites/maven-scala-plugin/). Maven handles > much more of the app lifecycle than ant does. Maven handles > documentation, testing, releases and building. I'm not saying that it is > necessarily easier but when you want to make a release, there is much > less work involved. > > In one command, maven can generate a web site, tag the svn, copy the > build to a location and publish the artefact on a repository to make it > available. > And then it can be distributed on the maven central repository, this > allows to add jscl to a project in one click. > Have a look at the current JEuclid web site. > >> Regarding a DOM export instead of XML text, I am not sure of what you >> mean. Currently XML export goes to a file, where is DOM supposed to go > ? > > DOM can go to several outputs; file or it could go directly to another > framework, JEuclid for instance. This way if you need to integrate > JEuclid and JSCL, you don't need to go back and forth to XML. Also, on > the code site, it is much nicer to generate rather than outputting xml. > >> What do you mean also with "bind variables to any java object" ? Do > you >> have an example ? > > Actually my needs are a even more complex... I have my own parser that > reads formulas from COBOL and I build my own tree for a formula. So I > will need somehow to use the tree model from JSCL and build manually the > formulas instead of using your parser. > And I have plenty of attributes attached to each variable (e.g. color) > and after a transformation in JSCL, I need to preserve these attributes. > This would require some simple refactoring that wouldn't break any > existing functionality. > >> Regading MathML, I'm currently researching in quite an opposed > direction >> to yours. I was thinking of using pMML2SVG to translate MathML to SVG >> and then get rid of Jeuclid altogether (I can't retrotranslate it to >> java 1.4 unlike everything else and such backward compatibility is >> important to me (It wouldn't be if scala didn't run on 1.4, but it > does, >> so java 1.6 is totally redundant here)). > > Let me know what issues you encounter, JEuclid should allow to go from > MathML to many different formats including SVG. I'm not sure what issues > you mention with JDK 1.4 but the most recent version of JEuclid runs on > every JDK version. You might be using an old version. The most recent is > 3.1.0. > >> Lastly, I am currently working on a port of jscl (and also/mainly JAS) >> to (hence) scala, so I am considering to freeze developments on jscl. >> Among others, the support for boolean algebra will be much better in > the >> new project. > > This sounds really great. I haven't found much support for Boolean > algebra in other projects so I might stick with JSCL. Are there any > chances you can preserve the tree model and parser part? (you shouldn't > need to redevelop that part in theory since scala is fully interoperable > with existing Java) I don't mind using JSCL even if it is evolving. > >> As as you see, our directions don't quite converge, but if you can > find >> something you can work on in what I cited, you are very welcome ! > > If there is a way that you can use a stable tree model for the upcoming > changes in Scala, I would be glad to help. > > Et s'il n'y a personne d'autre sur la liste, on peut causer en Francais > :-) > > Bests, > > Erik ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jscl-meditor-devel mailing list Jsc...@li... https://lists.sourceforge.net/lists/listinfo/jscl-meditor-devel |
|
From: Raphael J. <rap...@fr...> - 2008-11-01 19:02:59
|
Jeuclid : j'ai eu un gros problème de rendu de racine carré en pdf. J'utilise la version 3.0.3 avec un patch de mon cru. La dernière fois que j'ai regardé, aucune version de jeuclid n'était retrotranslatable vers 1.4, sans parler d'être dans cette version à proprement parler. Je télécharge les dernières versions et je regarde. Pour le reste, il faut que je voie ça au fur et à mesure (je suis un peu débordé en ce moment). Raphael Putrycz, Erik wrote: > Hi Raphael, > >> Regarding maven, if I understand it is like >> ant but more powerful. For the time being ant fulfills my needs, >> sometimes I even use simple shell scripts to build projects because I > am >> moving to scala and I don't know a ant/maven replacement for it. > > I converted the project to maven, plus I converted the testcases to > TestNG (instead of JUnit 3). > > There is a maven plugin for scala as well > (http://scala-tools.org/mvnsites/maven-scala-plugin/). Maven handles > much more of the app lifecycle than ant does. Maven handles > documentation, testing, releases and building. I'm not saying that it is > necessarily easier but when you want to make a release, there is much > less work involved. > > In one command, maven can generate a web site, tag the svn, copy the > build to a location and publish the artefact on a repository to make it > available. > And then it can be distributed on the maven central repository, this > allows to add jscl to a project in one click. > Have a look at the current JEuclid web site. > >> Regarding a DOM export instead of XML text, I am not sure of what you >> mean. Currently XML export goes to a file, where is DOM supposed to go > ? > > DOM can go to several outputs; file or it could go directly to another > framework, JEuclid for instance. This way if you need to integrate > JEuclid and JSCL, you don't need to go back and forth to XML. Also, on > the code site, it is much nicer to generate rather than outputting xml. > >> What do you mean also with "bind variables to any java object" ? Do > you >> have an example ? > > Actually my needs are a even more complex... I have my own parser that > reads formulas from COBOL and I build my own tree for a formula. So I > will need somehow to use the tree model from JSCL and build manually the > formulas instead of using your parser. > And I have plenty of attributes attached to each variable (e.g. color) > and after a transformation in JSCL, I need to preserve these attributes. > This would require some simple refactoring that wouldn't break any > existing functionality. > >> Regading MathML, I'm currently researching in quite an opposed > direction >> to yours. I was thinking of using pMML2SVG to translate MathML to SVG >> and then get rid of Jeuclid altogether (I can't retrotranslate it to >> java 1.4 unlike everything else and such backward compatibility is >> important to me (It wouldn't be if scala didn't run on 1.4, but it > does, >> so java 1.6 is totally redundant here)). > > Let me know what issues you encounter, JEuclid should allow to go from > MathML to many different formats including SVG. I'm not sure what issues > you mention with JDK 1.4 but the most recent version of JEuclid runs on > every JDK version. You might be using an old version. The most recent is > 3.1.0. > >> Lastly, I am currently working on a port of jscl (and also/mainly JAS) >> to (hence) scala, so I am considering to freeze developments on jscl. >> Among others, the support for boolean algebra will be much better in > the >> new project. > > This sounds really great. I haven't found much support for Boolean > algebra in other projects so I might stick with JSCL. Are there any > chances you can preserve the tree model and parser part? (you shouldn't > need to redevelop that part in theory since scala is fully interoperable > with existing Java) I don't mind using JSCL even if it is evolving. > >> As as you see, our directions don't quite converge, but if you can > find >> something you can work on in what I cited, you are very welcome ! > > If there is a way that you can use a stable tree model for the upcoming > changes in Scala, I would be glad to help. > > Et s'il n'y a personne d'autre sur la liste, on peut causer en Francais > :-) > > Bests, > > Erik |
|
From: Putrycz, E. <Eri...@nr...> - 2008-11-01 16:11:22
|
Hi Raphael, > Regarding maven, if I understand it is like > ant but more powerful. For the time being ant fulfills my needs, > sometimes I even use simple shell scripts to build projects because I am > moving to scala and I don't know a ant/maven replacement for it. I converted the project to maven, plus I converted the testcases to TestNG (instead of JUnit 3). There is a maven plugin for scala as well (http://scala-tools.org/mvnsites/maven-scala-plugin/). Maven handles much more of the app lifecycle than ant does. Maven handles documentation, testing, releases and building. I'm not saying that it is necessarily easier but when you want to make a release, there is much less work involved. In one command, maven can generate a web site, tag the svn, copy the build to a location and publish the artefact on a repository to make it available. And then it can be distributed on the maven central repository, this allows to add jscl to a project in one click. Have a look at the current JEuclid web site. > Regarding a DOM export instead of XML text, I am not sure of what you > mean. Currently XML export goes to a file, where is DOM supposed to go ? DOM can go to several outputs; file or it could go directly to another framework, JEuclid for instance. This way if you need to integrate JEuclid and JSCL, you don't need to go back and forth to XML. Also, on the code site, it is much nicer to generate rather than outputting xml. > What do you mean also with "bind variables to any java object" ? Do you > have an example ? Actually my needs are a even more complex... I have my own parser that reads formulas from COBOL and I build my own tree for a formula. So I will need somehow to use the tree model from JSCL and build manually the formulas instead of using your parser. And I have plenty of attributes attached to each variable (e.g. color) and after a transformation in JSCL, I need to preserve these attributes. This would require some simple refactoring that wouldn't break any existing functionality. > Regading MathML, I'm currently researching in quite an opposed direction > to yours. I was thinking of using pMML2SVG to translate MathML to SVG > and then get rid of Jeuclid altogether (I can't retrotranslate it to > java 1.4 unlike everything else and such backward compatibility is > important to me (It wouldn't be if scala didn't run on 1.4, but it does, > so java 1.6 is totally redundant here)). Let me know what issues you encounter, JEuclid should allow to go from MathML to many different formats including SVG. I'm not sure what issues you mention with JDK 1.4 but the most recent version of JEuclid runs on every JDK version. You might be using an old version. The most recent is 3.1.0. > Lastly, I am currently working on a port of jscl (and also/mainly JAS) > to (hence) scala, so I am considering to freeze developments on jscl. > Among others, the support for boolean algebra will be much better in the > new project. This sounds really great. I haven't found much support for Boolean algebra in other projects so I might stick with JSCL. Are there any chances you can preserve the tree model and parser part? (you shouldn't need to redevelop that part in theory since scala is fully interoperable with existing Java) I don't mind using JSCL even if it is evolving. > As as you see, our directions don't quite converge, but if you can find > something you can work on in what I cited, you are very welcome ! If there is a way that you can use a stable tree model for the upcoming changes in Scala, I would be glad to help. Et s'il n'y a personne d'autre sur la liste, on peut causer en Francais :-) Bests, Erik |
|
From: Raphael J. <rap...@fr...> - 2008-11-01 14:19:14
|
Hi Erik, Thanks for your interest. Regarding maven, if I understand it is like ant but more powerful. For the time being ant fulfills my needs, sometimes I even use simple shell scripts to build projects because I am moving to scala and I don't know a ant/maven replacement for it. Regarding a DOM export instead of XML text, I am not sure of what you mean. Currently XML export goes to a file, where is DOM supposed to go ? In a serialized object ? What are end users supposed to do with it ? BTW the internal representation is in DOM, so this would be easy. But I am currently planning to drop this for a text representation, more precisely a scala.xml.Elem representation, which is tantamount to a text representation. What do you mean also with "bind variables to any java object" ? Do you have an example ? Regading MathML, I'm currently researching in quite an opposed direction to yours. I was thinking of using pMML2SVG to translate MathML to SVG and then get rid of Jeuclid altogether (I can't retrotranslate it to java 1.4 unlike everything else and such backward compatibility is important to me (It wouldn't be if scala didn't run on 1.4, but it does, so java 1.6 is totally redundant here)). Lastly, I am currently working on a port of jscl (and also/mainly JAS) to (hence) scala, so I am considering to freeze developments on jscl. Among others, the support for boolean algebra will be much better in the new project. As as you see, our directions don't quite converge, but if you can find something you can work on in what I cited, you are very welcome ! Raphael Putrycz, Erik wrote: > I'm currently working on a project that needs to manipulate mathematical expression and after a lot of search, I found JSCL. > Among all the existing tools, what I like in JSCL are > - simplicity of core model > - export to MathML > - boolean algebra > > I'm a committer in the JEuclid project and my project does use also JEuclid to display formulas. > Few item where I'd like to contribute: > - build the project and publish with maven (I did this with the jeuclid project and db4o) > - improve connection with JEuclid and enable DOM export instead of XML text export (I already implemented this in my project) > - ability to bind variables to any java object, I have several internal attributes on each variables that I need to preserve through transformations > > Erik Putrycz, PhD - Research Associate |
|
From: Putrycz, E. <Eri...@nr...> - 2008-10-31 19:37:31
|
I'm currently working on a project that needs to manipulate mathematical expression and after a lot of search, I found JSCL. Among all the existing tools, what I like in JSCL are - simplicity of core model - export to MathML - boolean algebra I'm a committer in the JEuclid project and my project does use also JEuclid to display formulas. Few item where I'd like to contribute: - build the project and publish with maven (I did this with the jeuclid project and db4o) - improve connection with JEuclid and enable DOM export instead of XML text export (I already implemented this in my project) - ability to bind variables to any java object, I have several internal attributes on each variables that I need to preserve through transformations Erik Putrycz, PhD - Research Associate / eri...@nr... / (613) 990 0681 Institute for Information Technology - Software Engineering Group National Research Council, Canada - Building M-50, 1200 Montreal Road Ottawa, Ontario, CANADA K1A 0R6 |
|
From: Raphael J. <rap...@gm...> - 2008-05-21 18:08:40
|
news://news.gmane.org/gmane.comp.mathematics.jscl-meditor.announce news://news.gmane.org/gmane.comp.mathematics.jscl-meditor.devel news://news.gmane.org/gmane.comp.mathematics.jscl-meditor.user |
3 messages has been excluded from this view by a project administrator.
