2015-08-03 25 views
5

Mi piace molto l'ambiente live smalltalk (anche se ho solo sperimentato un po 'con Pharo), ma c'è una cosa che non posso davvero usare per lo sviluppo di tutti i giorni. Sembra che non sia possibile creare un eseguibile standalone nativo dal sistema smalltalk. L'eseguibile standalone nativo significa creare un singolo file eseguibile (PE su Windows, ELF su linux, Mach-O su macosx), che un utente potrebbe eseguire facendo doppio clic su di esso senza la necessità di installare ambienti di esecuzione aggiuntivi. Mi manca qualcosa ed è infatti possibile creare un eseguibile standalone nativo con smalltalk?Eseguibile standalone nativo con smalltalk?

Se parliamo di Pharo in particolare. So che l'ambiente di Pharo include un compilatore just in time efficiente (che genera un vero codice nativo dal bytecode VM di Pharo), so che l'immagine della VM può essere ridotta tagliando il codice che la mia applicazione non avrà mai bisogno. Quindi in pratica abbiamo già quasi tutto (tranne il linker credo) per poter creare eseguibili autonomi nativi. La compilazione incrociata non dovrebbe essere un problema anche se inseriremo tutti gli elementi di generazione del codice (per tutti i processori di destinazione) nell'immagine.

So che nel mondo smalltalk è considerata una buona cosa distribuire l'intera immagine VM separatamente dall'ambiente runtime, in modo che l'utente possa hackerare il software che sta utilizzando. Tuttavia non vedo alcun valido motivo per cui non dovrebbe essere possibile fornire il tuo software smalltalk come eseguibile indipendente compilato nativo. Potresti spiegarmi perché non è una cosa comune da fare nel mondo di smalltalk? Esiste qualche buona implementazione smalltalk che permetta di farlo?

Per riassumere tutto questo. Sogno un ambiente live smalltalk, dove potrei sviluppare e testare il mio software, ma poi (quando il software è effettivamente pronto per la consegna) cross-compilo a eseguibili nativi per windows, linux e macosx dalla mia singola macchina di sviluppo. Sarebbe davvero fantastico.

+1

Questo non è specifico per Smalltalk, ma per alcuni dialetti. Esistono diversi prodotti Smalltalk in un file .exe (ad esempio). –

risposta

1

Il problema è che Pharo, in questo caso, non può essere paragonato a nessun compilatore nativo come C, C++ o altri, ma più come java, python, ruby ​​e altri linguaggi con una macchina virtuale in giro.

In queste lingue, produci vasi, uova o gemme per distribuire il tuo progetto.

In Pharo, si produce una "immagine di produzione" seguendo le tecniche già citate. Ma nulla ti impedisce di consegnare un artefatto che includa anche il PharoVM (dopo tutto è largo 2 metri) e puoi preparare le tue app per rilevare e aprire la tua immagine di produzione (senza doverla chiedere).

+0

Altre VM + basate su immagini Smalltalks possono farlo. Il confronto è possibile. Questa non è una limitazione all'uso di immagini o VM. È semplicemente un problema della maturità di Pharo. –

3

ironicamente, c'è una cosa che un exe deve essere precaricato. Il tuo sistema operativo Vedete che C/C++ può essere così leggero perché già il vostro sistema operativo agisce più o meno come l'immagine agisce con una tonnellata di librerie precaricate. Hai bisogno di sprecare diversi GB di memoria per far partire una semplice calcolatrice. Il tuo sistema operativo è una raccolta di librerie C/C++.

Le cose non sono più carine con altri linguaggi come Python, Java ecc.

Pharo e Smalltalk in generale sono casi diffirenti perché aspirano a essere un sistema operativo virtuale di per sé. La diffidenza con un vero sistema operativo, l'immagine smalltalk è fatto per essere hackerato nel modo più semplice da un utente.

Dicendo che è possibile rinominare l'eseguibile pharo, cambiare la sua icona, disabilitare gli strumenti IDE all'interno di Pharo in modo che l'utente veda solo la GUI della propria app. Applicazioni come Dr. Geo e Phratch già fanno questo.

Compilare un progetto Pharo in un eseguibile nativo non farà molta differenza, perché a) Pharo è già compilato su un eseguibile nativo b) non è necessario farlo poiché Pharo è già standalone non è nemmeno necessario installarlo.

Il mio consiglio è smettere di preoccuparsi di cose che non contano davvero e divertiti a imparare come Pharo può essere potente e divertente.

+1

Il progetto SqueakNOS porta questa filosofia ancora di più, ma non richiede alcun sistema operativo (!) –

+3

Hai ragione nel fatto che non fa alcuna differenza reale per le dimensioni del download. Fa una grande differenza per l'utente finale dell'applicazione. Inoltre può fare la differenza per proteggere aspetti proprietari del codice. –

0

È quasi pratico con Smalltalk come con altre lingue: non molto. Non appena si crea un'applicazione un po 'più grande, si inizia a seconda delle altre librerie/applicazioni installate. Se li si compila staticamente con l'applicazione, ora si è creata un'applicazione molto più grande che richiede più tempo per il download e deve essere aggiornata almeno non appena viene rilevato un problema di sicurezza in una delle dipendenze. In caso contrario, l'applicazione non fa più clic con il doppio clic.

Ci sono due direzioni per le soluzioni: applicazioni web e installatori e gestori di pacchetti.

Squeak mantiene ancora il suo programma di installazione con un solo clic, consentendo allo stesso set di file di funzionare su Windows, Mac e Linux. Pharo lo usava anche lui, ma si è trasferito ad avere costruzioni separate. La necessità non è stata così grande che il build con un clic è stato ripristinato. È visto soprattutto come utile per essere in grado di portare in giro un ambiente multipiattaforma su una chiavetta USB. Con il passaggio allo spur vm a 64 bit, i problemi di dipendenza si attenueranno man mano che una maggiore quantità delle librerie necessarie verrà preinstallata su quelle piattaforme.

0

Il tuo sogno è in giro dalla metà degli anni '80 e si chiama Smalltalk/X.

6

Non Pharo, ma nativo, compilato (attraverso ANSI C o il proprio JIT) Smalltalk [applicazioni] (con possibilità di caricare DLL pre-compilati o [JIT-] compilare il codice su richiesta):

Smalltalk/X

http://www.exept.de/en/products/smalltalk-x.html

o (versione non ufficiale migliorata di sviluppo):

Smalltalk/X JV ramo - https://swing.fit.cvut.cz/projects/stx-jv/

Quasi completamente open source. Tutto tranne il compilatore di librun (core runtime - gestione della memoria, JIT, ecc.) E stc (smalltalk-to-c) è già open-source. Claus Gittinger/Exept ha anche promesso/confermato che avrebbero rilasciato le fonti rimanenti se dovessero interrompere ulteriormente lo sviluppo (AFAIK, quelle parti sono chiuse solo a causa di preoccupazioni dei clienti esistenti).

Consiglio vivamente a tutti di verificarlo, è una meraviglia che una così grande implementazione sia così poco conosciuta.

3

Si potrebbe anche controllare Dolphin da Object Arts.

È solo Windows, ma il migliore è lo IDE, nessuno escluso. Se fai qualcosa di in Smalltalk, dovresti comprarne una copia. (Hanno anche una versione gratuita non commerciale, ma tu vuoi voler sostenere il tipo di artigianato dietro acquistando la versione Pro. Un prodotto assolutamente kick-ass, IMHO).

Produrrà un exe standalone, se è quello che vuoi. Ho creato un wiki di medie dimensioni con esso - l'exe era meno di 1 MB. Non è un errore di battitura.

-Jim

+0

Dolphin è diventato open source. Puoi averlo gratuitamente e anche cercare la fonte! ;) (http://object-arts.com/blog/files/d60e38332cc3e009d1326504af95a64a-6.html) – ericvm

0

Dolphin Smalltalk può produrre un exe standalone per Windows.

Questa è una caratteristica chiave della versione Pro.