NSA - Non Solo Amiga
SOFTWARE => Programmi e applicazioni => Topic aperto da: ecalogiuri - 08 Agosto 2014, 11:16:34
-
Salve ragazzi,
volevo creare questa specie di diario per evidenziare come si evolve il mio editor testuale per programmatori.
Iniziamo con uno screenshot della scermata principale:
(http://fog76.altervista.org/img/Screenshot_CxEditor_Main.png)
Come vedete mancano ancora le icone, quelle saranno le ultime ad essere aggiunte.
Ecco l'edito in funzione sun un file object pascal + le opzioni di configurazione degli hightlighter.
(http://fog76.altervista.org/img/Screenshot_CxEditor_02.png)
Che ne pensate? :D :D
-
Che sta venendo su bene, da quel che si vede. :)
-
nell'ipotesi che
1) il tuo file editor sia multi tab, tanti file sorgenti, uno per tab
2) esista una interfaccia remota per il tuo editor
3) la current tab sia selzionabile da interfaccia remota
2) collegata all'interfaccia remota ci sia un altro modulo che si prende in carico il mapping {cpu.reg.PC} -> {file.s, riga}
tu hai modo di scrollare il sorgente e posizionare il cursore corrente all'indirizzo di linea proveniente dal modulo esterno ?
tipo, se il modulo all'interfaccia ti dicesse, "vai sul file pippo.s riga x", il che significa selezionare la tab giusta, e mettere il cursore alla riga giusta, tu potresti farlo ?
fammi capire, vorresti usarlo per fare jump diretto dai messaggi del compiler all'editor? :D
-
Bello! Ma... giusto così per sapere, la colorazione e la sintassi chi la controlla o come si configura? Ci sarebbe modo di customizzarla (anche pesantemente) per linguaggi "esotici" ;D
-
Forse non l'hai mai usato, ma queste cose le fa (comodamente) Visual Studio :)
-
ah boh, io ho lavorato sempre con roba ufficialmente supportata cotta e preparata che aveva il proprio plugin di integrazione con Visual Studio. Per fortuna mia non mi sono mai imbattuto in toolchain troppo stronze :)
Comunque ti linko un po' di cose potenzialmente interessanti:
- http://www.visualgdb.com/
- http://msdn.microsoft.com/en-us/library/bb147088(VS.100).aspx Reference (Visual Studio Debugging APIs)
- http://msdn.microsoft.com/en-us/library/bb161946(VS.100).aspx Getting Started with Debugger Extensibility
Se hai voglia e tempo di sbatterti, le API per agganciarsi al debugger sono pubbliche, e puoi scriverti il tuo connector per agganciare qualsiasi debugger a Visual Studio, e sfruttare così la sua "putenza di fuoco" :D
-
nell'ipotesi che
1) il tuo file editor sia multi tab, tanti file sorgenti, uno per tab
2) esista una interfaccia remota per il tuo editor
3) la current tab sia selzionabile da interfaccia remota
2) collegata all'interfaccia remota ci sia un altro modulo che si prende in carico il mapping {cpu.reg.PC} -> {file.s, riga}
tu hai modo di scrollare il sorgente e posizionare il cursore corrente all'indirizzo di linea proveniente dal modulo esterno ?
tipo, se il modulo all'interfaccia ti dicesse, "vai sul file pippo.s riga x", il che significa selezionare la tab giusta, e mettere il cursore alla riga giusta, tu potresti farlo ?
Allora per il punto 1 è proprio così! E si posso processare comandi esterni per posizionarmi sul file richiesto e posizione x,y, posso selezionare il testo, cambiarlo, inserirlo, criptarlo, selezionare tab, chiuderla o aprirla... insomma tutte le funzione che ha il mio editor possono eventualmente anche essere richiamate da "remoto".
Ora, cosa intendi per "Interfaccia remota?" Un, diciamo, demone in ascolto su una porta in particolare che processi dei comandi mandati via rete?
-
Bello! Ma... giusto così per sapere, la colorazione e la sintassi chi la controlla o come si configura? Ci sarebbe modo di customizzarla (anche pesantemente) per linguaggi "esotici" ;D
La colorazione è totalmente configurabile. Per linguaggi assembler si può facilmente prevedere un modulo per inserire nuovi highlighter. Per linguaggi più complessi, per come è adesso il codice, non lo permette. Deve essere definito hard-coded.
Mmmm.... però forse un modo ci sarebbe...
Vedrò 8)
-
ah boh, io ho lavorato sempre con roba ufficialmente supportata cotta e preparata che aveva il proprio plugin di integrazione con Visual Studio. Per fortuna mia non mi sono mai imbattuto in toolchain troppo stronze :)
Comunque ti linko un po' di cose potenzialmente interessanti:
- http://www.visualgdb.com/
- http://msdn.microsoft.com/en-us/library/bb147088(VS.100).aspx Reference (Visual Studio Debugging APIs)
- http://msdn.microsoft.com/en-us/library/bb161946(VS.100).aspx Getting Started with Debugger Extensibility
Se hai voglia e tempo di sbatterti, le API per agganciarsi al debugger sono pubbliche, e puoi scriverti il tuo connector per agganciare qualsiasi debugger a Visual Studio, e sfruttare così la sua "putenza di fuoco" :D
Grazie, Antonio, nel fine settimana me li smazzo. Questi link mi sono utilissimi, perché io faccio QA per i plug-in di Visual Studio che sviluppiamo, riguardo al debugging delle nostre architetture. ;D
-
Finalmente ho completato il demone TCP del CXEditor. Ecco la prima immagine che lo mostra in azione:
(http://fog76.altervista.org/img/Screenshot_CxEditor_03.png)
Ora devo solo impostare il set di comandi per poter controllare l'editor da remoto. Penso anche di implementare la trasmissione dati da CXEditor al computer remoto (tipo salvare in locale un file).
Bello eh? ;D ;D ;D
-
Se non fosse per quella roba Unix che vedo, sarebbe bellissimo.
-
Se non fosse per quella roba Unix che vedo, sarebbe bellissimo.
Tranquillo... è ricompilabile in Windows senza modificare una riga... anche in Unix se può interessare...
-
@ecalogiuri:
(a meno che io non sia scemo e lo hai già detto) che linguaggio+librerie hai usato per programmare l'editor? Ci si può dare una sbirciatina? :P
serve un minimo di infrastruttura X11, sotto Windows cosa usi ?
Dubito fortemente che abbia programmato direttamente in protocollo X11, altrimenti sarebbe uscito impazzito dopo 2 minuti! ;D
-
beh, l'idea e' di farlo girare su una macchina gentoo/x86 sotto X11
serve un minimo di infrastruttura X11, sotto Windows cosa usi ?
nel mio caso l'editor bovino gira addirittura sui router, tanto gli basta solo ncurses
che diventa un layer di compattibilita' CONIO nel caso DOS, se mai mi venisse la scimmia (e anche no)
Be dipende... Lazarus compila per GTK2 su Linux/Unix (ma si può compilare anche usanto Qt o GTK1), nativo Windows su Windows e Cocoa su Mac.
-
@ecalogiuri:
(a meno che io non sia scemo e lo hai già detto) che linguaggio+librerie hai usato per programmare l'editor? Ci si può dare una sbirciatina? :P
serve un minimo di infrastruttura X11, sotto Windows cosa usi ?
Dubito fortemente che abbia programmato direttamente in protocollo X11, altrimenti sarebbe uscito impazzito dopo 2 minuti! ;D
Lazarus con componenti nativi + synapse per i protocolli TCP/IP :-)
-
QT un bel po' di meno, questione di gentoo/portage (le QT rognano di +)
Più che altro se ora non si hanno più di 4GB di RAM, portage ti anticipa che non può compilare né QT né KDE e ti manda affanculo
si? hanno per caso reso obbligatoria la compilazione "fast" che impacca tutti i *.cpp in un solo file?
-
eh appunto, mi sembra l'unico motivo di fallimento. Personalmente ho usato la stessa tecnica su alcuni progetti (quando lavoravo nei videogames) e la compilazione si velocizza di brutto, ma pesa tantissimo sulla Ram per ovvi motivi. Anche in quel caso su macchine a 32 bit e/o con meno di 4GB di Ram poteva capitare il fallimento della compilazione.
-
@legacy
Penso di si, ma devo fare delle prove. Per me queste sono cose nuove. Vediamo se ho capito bene: tu vuoi che l'editor spedisca in remoto l'evento doppio click?
-
tu vuoi che l'editor spedisca in remoto l'evento doppio click?
esatto!
anche un messaggio che dice evento click, o doppio click
associato alla riga dove e' stato fatto il click
io poi pesco questa informazione e la giro al debug-protocol
dove sono previsti comandi per settare/rimuovere punti notevoli
Dovrebbe essere semplice, basta aggiungere una classe derivata che invece di leggere, spedisca. Magari domani faccio un test...
-
Se non fosse per quella roba Unix che vedo, sarebbe bellissimo.
Tranquillo... è ricompilabile in Windows senza modificare una riga... anche in Unix se può interessare...
No, è che sono allergico alle command-line e alla contorte sintassi dei comandi di Unix & co. ;D
-
Se non fosse per quella roba Unix che vedo, sarebbe bellissimo.
Tranquillo... è ricompilabile in Windows senza modificare una riga... anche in Unix se può interessare...
No, è che sono allergico alle command-line e alla contorte sintassi dei comandi di Unix & co. ;D
L'editor non usa nessuna linea di comando, quello in foto era un generico server tcp/ip. Potevo usarne uno windows in rete, ma ero al lavoro e quindi...
-
Sì, me n'ero accorto, ma è proprio la sola vista della command line che mi provoca conati di vomito...
-
Appunto: fai benissimo! Non c'è proprio paragone con gli script bash, che diventano rapidamente criptici e illegibili, ed è il motivo per cui mi fa schifo bash.
-
Continua il lavoro su CXEditor. Voglio solo segnalare il fatto che, per testare le connessioni TCP/UDP dell'editor, ho scritto un piccolo programmino di trasmissione e ricevimento di pacchetti. Un mio amico ha detto che è valido e mi ha consigliato di renderlo publico.
Perciò l'ho reso open source a questo indirizzo: http://ancestorsoftware.co.nf/ (http://ancestorsoftware.co.nf/)
Se volete, dateci uno sguardo.
Ciao,
Enzo.
-
Potrebbe servirti per controllare core eterogenei. ;)