Certaines communautés autour d'autre outil de developpement travaillent depuis des années, par leur travail collaboratif, ils ont mis au point des tas de composants , ils les ont combiné, empilé, dérivé. Ils sont arrivés à faire des choses ensembles sans forcement se reposer sur l'éditeur de leur outil, des choses que l'on imagine infaisable en abal.

Notre communauté est trés petite et le travail collaboratif ne fait pas partie de notre culture.
Tout le monde travail dans son coin.
Tout le monde réinvente ce que d'autre ont déjà surement fait puisque nous avons tous des besoins qui se recoupent.
Sing pourrait être l'outil fédérateur.
Depuis des années nous dépensons de l'énergie à faire nos propres outils d'impression, d'affichage , utilitaires divers etc... au lieu de nous concentrer sur ce qui est le plus important : nos applications ( organisation des données et les traitements )
Depuis des années on n'a pas pu capitalisé sur les développements passés car certains outils de développement que nous avons utilisé nous ont amené dans des voies de garage pour certains. Manque de temps, cout des développements etc... y sont aussi pour quelques choses.
Peut on espérer qu'un jour, prologue fournisse la structure ou l'aide pour qu'une communauté de développeur du monde prologue digne de ce nom existe et produise un travail collaboratif aussi réussi que ce que l'on peut trouver dans d'autre communauté.
Prologue avait annoncé il y a longtemps qu'il n'avais pas vocation à fournir des composants.
Mais est ce qu'aujourd'hui, un outil de développement sans composants standard et usuel peut encore attirer des développeurs ?
Je ne critique pas sing, ce que j'en ai vu et ce que j'ai expérimenté me donne de l'espoir pour l'avenir.
Mais de nos jours, tout doit aller vite, au moindre coup.

L'efficacité et la robustesse des applications abal/criteria, éprouvées depuis longtemps, résistent encore aux applications réalisées avec d'autres outils, mais pour combien de temps encore. Cela devient de plus en plus dur.

Pardonnee' moi mon francais:

Come disez Obelix en: Le laurier de Cesar

Parfaitement!

Puntualizzo il mio concetto in italiano:
Anche se Abal o Sing sembrano essere Asterix ed Obelix contro il resto del mondo, l'importante e' resistere e non morire come hanno fatto molte altre realta' (vedi NOVELL).
IBM e' stata affondata da microsoft ed ora si e' alleata col resto del mondo che e' LINUX e JAVA, quindi il resto del mondo affossera' la microsoft.
Alla fine chi restera' vivo raccogliara' i resti di questa guerra epica fatta tutta sulla base dell'ultima novita' tecnologica.
Va bene Sing se ci permette di proseguire e vedere l'alba della vera era informatica, quella di HAL 9000 (Space Odissey di Kubric), ma senza bugie ai computer.

Salut

Gianni peut-on avoir une petite traduction s'il te plait ?

English for this evening:

I'm making my concept clear:
Even if Abal or Sing seem to be like Asterix and Obelix against the whole world, the most important thing is to resist and not to die as others did (like Novell).
IBM was sink by microsoft and now formed an alliance with the rest of the world, which is Linux and Java, so that the rest od the world will sink microsoft.
In the end the once still alive will pick up the remains of this epic war all based on the latest technologic innovation.
It's fine if sing allow us to go on and see the dawn of the true computer science era, the one of HAL 9000(Space Odissey di Kubric) but without any lie to computers


ciao
gianni

Je fait le point sur ma conception:

Meme si Abal ou Sing ressemblente à Asterix et Obelix contre le reste du monde, ce qui compte c’est résister et ne pas mourir comme beaucoups d’autres stituations (comme NOVELL).
IBM a été coulée par microsoft et maintenant elle s’est alliée avec le reste du monde qui est LINUX et JAVA, donc le reste du monde coulera la microsoft.
A la fin qui vivra retrouvera les reste de cette guerre épique faite sur la base de la dernière nouveauté technologique.
C’est bien si Sing nous permet de continuer et de voir l’aube de la vraie ère informatique, celle de di HAL 9000 (Space Odissey de Kubric), mais sans mensonges des ordinateurs.

ciao
gianni

sing est fait en abal+visual ?
est-il possible de demander à prologue que les sources abal qui composent sing soient libre d'acces, afin de faciliter le travail communautaire qui pourrait etre fait?

Je ne crois pas soit important comme soit écrit Sing mais qu'est-ce que SING et, comme il dit Stefane, quel saura son futur. Je crois que Sing soit fondamentalement un Editor graphique qui rappelle des instructions présentes en ABAL3, il ne s'agit pas d'un nouveau langage mais il permet d'utiliser mieux ABAL3. Fin qua' ; pas de problèmes s'il n'était pas qu'il faut récupérer les vieux sources. En effet les premières critiquex que j'ai senti à SING sont : Ils n'ont prévu aucun système d'importation ou conversion même pas pour les applications ABAL2 plus récents deja' ecrites en prévoyant le mouse. En somme SIng semble être posé dans un ' TOUR D' AVOIRE' lointaine des pauvres besoins des vieux programmatori ABAL2. Le motive existe sûrement et e'; identifiable du fait que les applications objets à écrire avec ABAL3 doivent passer à travers des nouvelle analisi et donc recriture, donc e' inutile chercher à importer des vieux flux incompatibles. Je peux assurer que la situation pas e' vraiment ainsi grave : E' possible continuer faire vieux et efficaces analisi TOP-DOWN ou les sequenziali typiques d'applications ABAL2 et les voir fonctionner avec les nouvelles instructions graphiques ABAL3 parmi lesquelles VisualEdit. Il reste seul le problème de la gestion des Évènements qu'on peut résoudre brillantement dans beaucoup de modalités et dont je propose le mien, certes qu'ils suivront beaucoup de vos exemples. Les exemples annexes n'ont pas besoin de criteria mais seulement de la librairie FLFILE pour l' accès direct. Volutamente sont les plus vieux (et sans graphique) mais pour cela je crois ils soient même plus simples et ils peuvent illustrer par des exemples comme e' possible utiliser les évènements en ABAL2 et par conséquent même en ABAL3. le motive e' RÉCUPÉRER les VIEUX SOURCES et les adapter à la nouvelle programmation à objets. Si quelqu'un e' intéressé j'ai deja' écrit des programmes de conversion et j'utilise mes precompilateurs pour traduire en ABAL le pseudo méthodes écrites dans mon metalanguage. En annexe INSDIT.at et EXPLAIMS.at complets d'archives et des principales sources constitutives, en particulier EXPLAIMS crée un pseudo-ISAM en utilisant le simple file virtuel de ABAL, aucune des deux a besoin de la partie SI-MC de criteria. EXPLAIMS a TOUS les sources composantes.
Le troisieme example E_FAT s'agit de quelque chose plus puissante avec de PseudoObject et il faut l'appeler aver E_FAT.bat.

EXPLAIMS.as e son #include RUNTAIMS.as et RUNVAIMS.as on ete traduit en autre language (c# standardt) merci at la facon de n'outiliser jamais que de simple instruction pour gerer l'evenement.
De telle facon mes source deviennent portable, peut-etre aussi en SING.

Saluts de Pierluigi

Dans ma la langue et de Dante ALighieri:
-----------------------------------------------
Non credo sia importante come e' scritto Sing ma che cosa e' SING e, come dice Stefane, quale sara' il suo futuro sviluppo.

Io credo che Sing sia fondamentalmente un Editor grafico che richiama istruzioni presenti in ABAL3, cioe' non si tratta di un nuovo linguaggio ma permette di utilizzare meglio ABAL3.

Fin qua' nessun problema se non fosse che occorre recuperare i vecchi sorgenti.
Infatti le prime critiche che ho sentito a SING sono:
Non hanno previsto nessun sistema di importazione o conversione nemmeno per le applicazioni ABAL2 piu' recenti scritte gia' prevedendo il mouse.
Insomma SIng sembra essersi posto in una 'TORRE D'AVORIO' lontana dai poveri bisogni dei vecchi programmatori ABAL2.
Il motivo esiste sicuramente ed e' identificabile dal fatto che le applicazioni ad oggetti da scrivere con ABAL3 devono passare attraverso una nuova analisi e quindi riscrittura totale, quindi e' inutile cercare di importare vecchi flussi incompatibili.

Io posso assicurare che la situazione non e' proprio cosi grave:
E' possibile continuare a fare le vecchie ed efficaci analisi TOP-DOWN o sequenziali tipiche di applicazioni ABAL2 e vederle funzionare con le nuove istruzioni grafiche ABAL3 tra cui VisualEdit.
Rimane solo il problema della gestione degli EVENTi che si puo' risolvere brillantemente in molti modi e di cui io propongo il mio, certo che seguiranno molti vostri esempi.

Gli esempi allegati non hanno bisogno di criteria ma solo della libreria FLFILE per l'accesso diretto.
Volutamente sono i miei piu' vecchi (e senza grafica) ma per questo credo siano anche piu' semplici e possono esemplificare come e' possibile utilizzare gli eventi in ABAL2 e di conseguenza anche in ABAL3.
Il motivo e' RECUPERARE I VECCHI SORGENTI ed adattarli alla nuova programmazione ad oggetti.

Se qualcuno e' interessato ho gia' scritto dei programmi di conversione ed utilizzo un mio precompilatore per tradurre in ABAL i pseudo metodi scritti nel mio metalinguaggio .

In allegato trovere INSDIT.at e EXPLAIMS.at entrambi completi di archivi e dei principali sorgenti costitutivi, in particolare EXPLAIMS crea un pseudo-ISAM utilizzando il semplice file virtuale di ABAL, nessuno dei due ha bisogno della parte SI-MC di criteria.
EXPLAIMS ha TUTTI i sorgenti componenti.

Il terzo esempio E_FAT si tratta di qualcosa di piu' potente con dei PseudoOggetti e occorre eseguirlo con E_FAT.bat.

EXPLAIMS.as e i suoi include RUNTAIMS.as e RUNVAIMS.as sono stati tradotti in altri linguaggi (c# standardt) grazie al modo di non utilizzare mai che delle semplici istruzione per gestire gli Eventi, in questo modo i miei sorgenti diventano portabili, forse anche in SING.

Saluti da Pierluigi




Attached File ( Number of downloads: 141 )
 DEMO.zip

Jamie pourrait nous en dire plus, mais sing est un executable windows donc à priori ce n'est pas du TCODE ABAL.
A moins que prologue nous cache des choses et qu'il est possible de transformer un .AT en .exe ;-)
Jamie peux tu nous en dire plus ?


Petite remaque sing affiche des données sous forme d'arborescence ( structure du projet ). A l'heure actuelle, il n'existe pas de widget ou de composant sing permettant de faire de telle chose. Sing l'utiliserait et on ne donnerait pas la possibilité au developpeur de l'utiliser dans leur programme , un comble non ?

Transformer en EXE e pourquoi non passer aux autres language.
In Italien: Trasformare in EXE e perche' non scrivere direttamente in un altro linguaggio

Sing peut ecrire aussi en C# ?

sing peut produire du code autre qu'abal oui
Donc sing produit peut etre du C pour ses propres besoins
Sing est utilisé pour faire Sing si je ne me trompe pas

ballista le problème n'est pas là
Le pb n'est un .exe ou pas un .exe

La question d'yvonne est de savoir si sing est un programme abal, si c'est le cas ,elle souhaite que les sources soient public pour éviter le même problème que celui rencontré avec SCREENER et permettre à ceux qui le voudrait et le pourrait corriger des bugs !!!
C'est bien ca Yvonne ?

A l'origine, sing était utilisé pour produire sing.
Est ce que c'est toujours le cas, seul Jamie pourrait nous répondre.

Que sing utilise sing pour produire sing le problème n'est pas la non plus

Sing n'est qu'un outil
Il produit du code abal sous une certaines forme et organisation qu'il ne vaut mieux ne pas toucher ou bricoler.
Mais la base reste que c'est du code ABAL qui utilise toutes les BDA disponibles ( Visual , BD@NET etc...) et des Classes ( Programmation orientée Objet) disponibles.

Sing produit rapidement énormément de code.
si certains veulent coder à la mano pour produire l'équivalent de ce que sing fait, bon courage .......

Soit on utilise les fonctionnalités de relookage des applications texte avec les ATB
Soit on réécrit à la mano avec Visual les écrans sous forme de formulaire Visual( Y a du travail à aussi)
Soit on utilise Sing qui facilite grandement là chose.

On peut ne pas vouloir faire confiance à Sing mais dans ce cas il faut bien s'appuyer sur quelques choses ( Visual ) et coder à la mano .

Ensuite que sing n'en face pas encore assez, c'est un autre problème.

Sing évolue régulièrement et toujours pas assez vite pour nous ;-)

Ballista semble vouloir proposer une solution alternative pour la gestion des événements.
Nos amis italiens peuvent peut-être nous éclairer j'ai un peu de mal à suivre sa conversation en francais et je ne lit pas l'italien :-(

Soyons claires : Toutes les sources "Abal" de "Sing", sont déjà à votre disposition, livrées
avec le produit !

Cependant "Sing" a été écrit en langage "C", comme les autres outils d'abal depuis
toujours et ceci a fin de permettre son évolution a travers ces derniers 20 années
sur des systèmes divers et variées et des machines d'architectures au pointe de la
technologie.

La langage "Abal" avait été conçu en tant que "amplificateur" de la puissance du langage
"C". La développement en langage "C" n'est pas aussi facile pour la gestion qu'en "Abal",
sauf si on se fait sa propre système semblable.

O.S.Q.

Cher Stefane, comme tu vois aucun ami italien a répondu. De toute façon tu il éprouve à me faire des questions et je te répondrai en cherchant la meilleure traduction possible Je motive de mon insistance est qu'avec mon simple système on pourrait déjà être fortement avancé nell'emploie de sing, en sautant à pied pairs tous les problèmes engendrés du paradigme de la programmation à des objets, surtout en ce qui concerne le mécanisme des évènements

L'interet de sing n'est pas que la gestion des événements.
Sing apporte un peu plus que cela.

Quelqu'un a t'il testé l'exemple de ballista ?
Qu'en pensez vous ?