Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Topics - caronte

Pagine: [1] 2
1
Altri linguaggi / Asm + Python...?
« il: Luglio 10, 2013, 16:37 »
Salve genteeee (ogni tanto vi vengo a tediare..anke se vi ho sempre sotto controllooo   :vampire:)

Qualche giorno fa sono inciampato in questo modulo : TDASM   che praticamente consentirebbe  di scrivere  codice ASM inline con python…in linea di massima come avverrebbe in C .
Ci sono installer  vers. 0.2 a 32 e 64 bit per windows su Python 3.2, e come dichiarato anche per Linux, ma io vedo solo il sorgente  del la vers. 0.1….mha..comunque potete farvi in giro sul sito per requisiti ecc..anche se la documentazione pare ancora abbastanza esigua…

In linea di massima l’utilizzo  sembra molto semplice e consta di 5 step fondamentali e ve lo riporto paro paro dal sito:

http://www.tahir007.com/news

For executing assembly source you will always have these steps:


1.   Use Tdasm to produce machine codes from assembly sources
2.   Use Runtime to put that machine codes in system memory
3.   Use DataSection to put some values in variables
4.   Use Runtime to execute machine code
5.   Use DataSection to extract values from variables

Ho subito provato qualcosa di semplice,  inserendo in python un codice MASM leggermente  ‘adattato’  che compara due 4 bytes integer   ne decrementa solo il minore; non ho usato direttive di alto livello in quanto pare che le uniche ammesse al momento sono : data, code ed end (considerato come un semplice return al codice python)

Sta girando su un intel X64….

[codice]
from tdasm import Runtime, Tdasm

def compare():
    asm_source = """
    #DATA
    int32 x, y

    #CODE
    if01:
    mov eax, dword

    cmp eax, dword [y]
    jl else01
    then01:
    dec dword

    jmp endif01
    else01:
    dec dword [y]
    endif01:
    nop

    #END
    """
    machine_code = Tdasm().assemble(asm_source)
    r86 = Runtime()
    ds = r86.load("inc", machine_code)
    ds["x"] = 88
    ds["y"] = 99
    r86.run("inc")
    print(ds["x"], ds["y"])

compare()
[/codice]

Vorrei avere qualche parere da voi guruss , magari  qualcuno l’ha   già provato…testato..
Da quello che ho capito non si possono usare alcune “direttive   di alto livello ” come  .if ,.else. untilcxz, .repeat..ecc… insomma sembra che ci siano comunque limiti al codice supportato, infatti in molti esempi che fa, invece di usare tali direttive, lavora a basso livello con i relativi operatori : cmp, jmp, jle, le labels, ecc..diversamente le macro sono supportate, insieme alle istruzioni dello stack… ma, ripeto, è probabilissimo che  stia  sbagliando io non riuscendo  ad implementarle…, o ad adattarle…bhooo

qualche parere?..anche sulla relativa usabilità del modulo?
leggendo qualcosa in rete è uscito fuori il parere del "Guido", contrario all'utilizzo inline dell'assembly proprio per il problema di portabilità...ma secondo me è una 'cosa' molto figa...

2
Base / problemi con makefile method
« il: Marzo 03, 2013, 22:24 »
Ciao raga
Ho bisogno di una delucidazione riguardo al seguente script che rappresenterebbe un estratto  di un esempio fatto da Lutz e che ho riportato in un unico file per isolare la ‘questione’:
in breve un server ed un client(su processi asyncroni ) comunicano in locale tramite un file associato al socket  mediante il metodo s.makefile:

[codice]
import sys, os,  multiprocessing
from socket import *
port = 50008            # pass in different port if multiple dialogs on machine
host = 'localhost'      # pass in different host to connect to remote listeners

def initListenerSocket(port=port):
    """
    initialize connected socket for callers that listen in server mode
    """
    sock = socket(AF_INET, SOCK_STREAM)
    sock.bind(('', port))                     # listen on this port number
    sock.listen(5)                            # set pending queue length
    conn, addr = sock.accept()                # wait for client to connect
    return conn                               # return connected socket

def redirectIn(port=port, host=host):
    """
    connect caller's standard input stream to a socket for GUI to provide
    """
    sock = socket(AF_INET, SOCK_STREAM)
    sock.connect((host, port))
    file = sock.makefile('r')                 # file interface wrapper
    sys.stdin = file                          # make input come from sock.recv
    return sock


###############################################################################
# redirected client input
###############################################################################

def server2():
    mypid = os.getpid()                              # raw socket not buffered
    conn  = initListenerSocket()                     # send to client's input
    for i in range(3):
        conn.send(('server %s: %s\n' % (mypid, i)).encode())

def client2():
    mypid = os.getpid()
    redirectIn()
    for i in range(3):
        data = input()                               # input from socket
        print('client %s got [%s]' % (mypid, data))

if __name__ == '__main__':
    server = eval('server' + sys.argv[1])
    client = eval('client' + sys.argv[1])               # client in this process
    multiprocessing.Process(target=server).start()      # server in new process
    client()
[/codice]

però quando lancio lo script da shell mi riporta il seguente errore:

Traceback (most recent call last):
  File “…/    …prova-red.py", line 76
, in <module>
    client()
  File "…./… prova-red.py", line 69
, in client2
    data = input()            # input from socket
  File "<string>", line 1
    server 4196: 0
              ^
SyntaxError: invalid syntax


Non so se sbaglio ma sembra che lo stdin  reindirizzato del client  non riesca a leggere dal socket I dati inviati dal server sempre sul medesimo file object …eppure dovrebbe fungere
Da cosa potrebbe dipendere?
Grazie in anticpoooo

3
Python-it.org cafè / text editor per IPad
« il: Febbraio 13, 2013, 22:31 »
Salve gente
poichè , contro ogni mia morale, ho dovuto regalare codesto 'gioiello' di casa apple a mio padre per consentirgli di usare agevolmente  skype e leggersi qualche news in rete senza dover accendere ed accedere a  pc vari...mi servirebbe appunto un benedetto text editor ma che sia in ITALIANO!!!!, ovvero che abbia almeno il main menu   in lingua italica...sto girando da una mezz'oretta in rete e ce ne sono un'infinitààààà (ovviamente tutti a pagamento, ma ho visto che costano poco quindi...) ma che voi sappiate,  ne esiste uno che sia  almeno multilingue????... visto che per la maggior parte sono in inglese, francese e tedesco...?
consigli?? mi sta stressandoooo

4
Base / chiarificazione sui *thread*
« il: Febbraio 02, 2013, 19:44 »
Salve ragassi
vorrei  delucidazioni basilari  sui threads , utilizzando il classico modulo _therad: a riguardo sto seguendo la guida di Lutz, nella quale è specificato che :
"""…..Files and streams, for example, are shared by all threads in a program; if multiple threads write to one stream at the same time, the stream might wind up with interleaved, garbled data. Even simple changes can go awry if they might happen concurrently…"""
Infatti in un suo esempio  utilizza un lock per sincronizzare l’accesso ad un  comune stream…da parte di threads che scorrono  in parallelo.., ma a questo non dovrebbe provvedere automaticamente il GIL?

Riporto l’esempio  sostituendo lo sleep sulla main con un ciclo while ed una flag in modo che la main termini nel momento in cui tutti i therads terminino:

[codice]
# su Python 3.2
import _thread as thread, time

flag = [False] * 5
def counter(id, count):    
    for i in range(count):
        time.sleep(0.5)          
        mutex.acquire()   # qui  
        print('[%s] => %s' % (id, i))  
        mutex.release()     # qui
    flag[id] = True

mutex = thread.allocate_lock()  # qui

for i in range(5):
    thread.start_new_thread(counter, (i, 5))

while False in flag: pass
print('Main thread exit.')

[/codice]

se lo riscriviamo eliminando il ‘lock’ come da commenti  il processo funge comunque, senza pericolo di overlap sullo stream…quindi come stanno le cose? mi sfugge qualcosa…?
grazie in anticipooo


5
Altri linguaggi / tail-end recursion in Python.....??
« il: Settembre 17, 2012, 20:26 »
Forse ancora non m’è chiaro il concetto di tail-end recursion in un linguaggio funzionale , ma mi pare di aver capito che  per evitare un “accumulo fino allo “stack ", abbiamo bisogno, nella nostra funzione ricorsiva,  di un parametro extra  a cui passare come argomento un accumulatore  del valore ritornato appunto dalla precedente  “chiamata ricorsiva” della nostra funzione;
 bene (o male ..)..la guida che sto seguendo su OCaml afferma che tale soluzione non viene implementata in un linguaggio come Python…
Ma…comuqnue prendiamo  la seguente funzione tail-end recursion  in OCaml: …

# let rec fsum_acc cont n =
  if n = 1
      then cont + 1
  else (fsum_acc (cont + n) (n - 1));;
val fsum_acc : int -> int -> int = <fun>
# let fsum = fsum_acc 0;;
val fsum : int -> int = <fun>

Quindi in parallelo definiamo la ‘relativa’ funzione anche in Python :
 tralasciando il fatto  che in python ce la possiamo giocare   anche con qualcosa tipo:

[codice]
from functools import reduce
def t_rec(n):
    return reduce(lambda x, y: x + y, range(abs(n) + 1))
[/codice]

Definiamo la funzione in parallelo (passo passo più o meno...) a quella in OCaml:

[codice]
def  tail_recur (n, acc=0):
    if n < 0: print('infinite rec')
    elif n == 1:
        acc += 1
        print('sum is: ', acc)
    else :
        acc += n
        return tail_recur((n-1), acc )
[/codice]

Probabilmente sbaglio, ma a me sembra di aver seguito la medesima semantica della tail-end  rec
O sono ancora fuori strada??


6
http://www.squidoo.com/which-programming-language-is-best

Essendo proprio alle prime armi, un vero niubbo , ricercando in rete mi sono imbattuto nella suddetta classificazione(o meglio contestualizzazione)  relativa ai più 'importanti' linguaggi di programmazione...
vorrei sapere cosa voi ne pensiate  a riguardo, magari evidenziandone eventuali inesattezze o altro, ed eventualmente buttar giù una vostra ' personale ridefinizione' di tale classifica...
grazie! :) :)

7
Base / Su getattr built-in...
« il: Luglio 27, 2012, 21:47 »
Salve gente
vi riporto il  codice basato su un esempio preso dalla guida che sto seguendo, ma non capisco perchè venga usato getattr in tale contesto :

[codice]bob = {'name': 'Bob Smith', 'age': 42, 'pay': 30000, 'job': 'dev'}
sue = {'name': 'Sue Jones', 'age': 45, 'pay': 40000, 'job': 'hdw'}
tom = {'name': 'Tom', 'age': 50, 'pay': 0, 'job': None}

import shelve
db = shelve.open('shelve_people')
db['bob'] = bob
db['sue'] = sue
db['tom'] = tom

db.close()

fieldname = ('name', 'age', 'job', 'pay')
maxfield = max(len(f) for f in fieldname)
db = shelve.open('shelve_people')

while True:
    key = input('\nkey? => ')
    if not key : break
    try:
        record = db[key]
        print(db[key])
    except:
        print('key "%s"! non esiste' % key)
    else:
        for field in fieldname:
            print(field.ljust(maxfield), getattr(record, field))[/codice]

non so se mi sfugga qualcosa ma usare getattr su un dizionario non dovrebbe fungere:
infatti qui 'field'  è la key del diz. record e ovviamente non un attributo...(eppure il libro ne riporta la correttezza logica...il che mi confonde un bel po...)
infatti se cambiamo il codice come segue, il tutto funge:

[codice]
........( )..
while True:
    key = input('\nkey? => ')
    if not key : break
    try:
        record = db[key]
        print(db[key])
    except:
        print('key "%s"! non esiste' % key)
    else:
        for field in fieldname:
            print(field.ljust(maxfield), db[key][field]) [/codice]

mi illuminereste a riguardo??
grazie ini anticipo...

8
Base / Decoratore e ciclo for...
« il: Giugno 01, 2012, 20:51 »
Salve gente
sto cercando di terminare questa parte d'approfonidmento sui decoratori, che all'inizio mi erano alquanto antipatici, ma stanno acquistando carisma  :)
Allora quest’ultimo è un esercizio/esempio sull’utilizzo appunto dei decoratori per validare gli argomenti( posizionali, keywords e default-args) passati ad una funzione.L’esempio in se, in effetti , non da problemi...
quindi postiamo il codice :
3.2
[codice]def argtest(**dec_arguments):
    def func_decorator(func):
        if not __debug__:
            return func
        else:
            code = func.__code__
            allargs = code.co_varnames[:code.co_argcount]
            funcname = func.__name__

            def call(*pargs, **kargs):
                positionals = list(allargs)
                positionals = positionals[:len(pargs)]

                for (key, (low, high)) in dec_arguments.items():
                    print(key,(low, high)) # trace per le iterazioni
                    if key in kargs:
                        print('trace kargs')
                        if kargs[key] < low or kargs[key] > high:
                            errorprint = ('{0} argument "{1}" '
                                          'not in {2}..{3}').format(funcname, key, low, high)

                            raise TypeError(errorprint)
                    elif key in positionals:
                        print('trace pargs')
                        position = positionals.index(key)
                        if pargs[position] < low or pargs[position] > high:
                            errorprint = ('{0} argument "{1}" '
                                          'not in {2}..{3}').format(funcname, key, low, high)
                            raise TypeError(errorprint)
                    else:
                        print(('Argument {0} is default').format(key))
                return func(*pargs, **kargs) # se invece lo 'indentiamo' nel ciclo for
                                             # quest'ultimo si blocca
            return call
    return func_decorator


@argtest(a=(1, 10), b=(1, 10), c=(1, 10), d=(1, 10))
def defargs(a, b=7, c=8, d=9):
    print(a, b, c, d)

defargs(d=4, a=1)[/codice]

ma se ad esempio decidessi(ovviamente per puro scopo 'dimostrativo') di inserire il return della funzione defargs all’interno del ciclo for allora qualcosa non mi torna:
[codice] for (key, (low, high)) in dec_arguments.items():
#                    ....(omit)
                    else:
                        print(('Argument {0} is default').format(key))
                    return func(*pargs, **kargs)[/codice]
ovvero il ciclo for , dopo la prima ,non termina più tutte le sue  iterazioni e non ho ancora capito il perché..!!sicuranente c’è una spiegazione più che ovvia ma che ancora non mi è chiara…mmmmhh
però raga se è proprio palese e semplice il motivo avvertitemi senza spiegarmelo! così stanotte(perchè adesso so stanco) prima di andare  a dormire mi ci rimetto su!!adesso so un po fusoooo... :thinking: :) :)
thanks in advance  :py:

9
Base / info su decoratore...
« il: Maggio 22, 2012, 17:49 »
bonjour
vi rubo due minuti..
sto cercando di approfondire (o almeno ci provo) lo studio dei decoratori...
ma sto avendo un problema nel capire un aspetto del seguente codice:
[codice]def tracer(func):
    calls = 0
    def wrapper(*args, **kwargs):
        nonlocal calls
        calls += 1
        print('call %s to %s' % (calls, func.__name__))
        return func(*args, **kwargs)
    return wrapper

@tracer
def spam(a, b, c):
    print(a + b +c)
    
spam(1, 2, 3)[/codice]

OK, fin qui tutto bene, però stando alla definizione immediata di un decoratore, se poniamo:
[codice]tracer(spam(1, 2, 3))[/codice]
eliminando ovviamente '@tracer' dalla definizione di spam, dovrei ottenere il medesimo output, ma ecco che mi printa solamente : 6 ;
quindi è come se non chiamasse la wrapper del decoratore...e qui mi sò perso...e mi domando  come mai? :sarcastic:
cosa mi sta sfuggendo?
grazie in anticipo   :question:

10
Base / descrittori e strano debugging...
« il: Maggio 11, 2012, 14:27 »
Scusate se approfitto ancora della vostra immensa pazienza, ma sto avendo un  problema nel  debugging del codice della seguente simulazione molto 'basilare' della  Property :
 ovvero quando lo 'forzo' nel sollevare il raise del metodo __set__, nel debug  subito dopo la traceback, stranamente(almeno per me..), mi continua  a richiamare il __get__  method :

[codice]#3.2
class Property:
    def __init__(self, fget=None, fset=None, fdel=None, doc=None):
        self.fget = fget
        self.fset = fset
        self.fdel = fdel
        self.__doc__ = doc
    def __get__(self, instance, instancetype=None):
        if instance is None:
            return self
        if self.fget is None:
            raise AttributeError("can't get attribute")
        return self.fget(instance)  
    def __set__(self, instance, value):
        if self.fset is None:
            raise AttributeError("can't set attribute")
        self.fset(instance, value)
    def __delete__(self, instance):
        if self.fdel is None:
            raise AttributeError("can't delete attribute")
        self.fdel(instance)

class Person:
    def __init__(self, name):
        self._name = name
    def getName(self):
        print('call getName') #perchè dopo il raise me lo chiama altre 4 volte?
        return self._name
    def setName(self, value):
        print('call setName')
        self._name = value
    def delName(self): pass
        
    name = Property(getName) #omettiamo setName per forzare il raise del metodo __set__....
    
X = Person('Pippo')
X.name = 'Ugo'
print(X.name)
[/codice]

debug:
[codice]Traceback (most recent call last):
  File "D:\Pythonorelly_script\Es_Parte_VI.py", line 503, in <module>
    X.name = 'Ugo'
  File "D:\Pythonorelly_script\Es_Parte_VI.py", line 482, in __set__
    raise AttributeError("can't set attribute")
AttributeError: can't set attribute
call getName
call getName
call getName
call getName
[/codice]

non me ne sarei mai accorto se non avessi aggiunto una 'trace' nel metodo getName della classe client...il quale comunque  non mi restituisce il return...
come mai accade ciò?? sicuramente mi sfugge qualcosa... :( :( :(
grazie anticipatamente!!!

11
Base / appunto sui descrittori...
« il: Maggio 08, 2012, 19:45 »
Salve gente,
vorrei una piccola delucidazione riguardo al ‘comportamento’ del seguente codice, di cui, almeno superficialmente, ho capito il ‘processo’..ma non mi è chiaro un aspetto:

[codice]class Descriptor(object):
    def __get__(self, istance, owner):
        print(self, istance, owner, sep='\n')
        return 'ok'
       
class Subject:
    attr = Descriptor()

X = Subject()
print(X.attr)[/codice]

ok, quindi X.attr è come se chiamasse :  Descriptor.__get__(Subject.attr, X, Subject); bene, ma quello che non mi è chiaro è il  perchè ‘Subject.attr' (che è sia attributo della classe Subject ma anche  istanza della Descriptor) non invoca a sua volta il metodo __get__?.. ma invece tutto fila liscio…
teoricamente dovrebbe farlo, giusto?...infatti :
[codice]#infatti se poniamo:
Subject.attr
#il metodo __get__ viene comunque invocato...
[/codice]
grazie anticipatamente!

12
Base / su overridding... precisazione
« il: Aprile 12, 2012, 20:04 »
Salve Ragazzi
 allora ho un problemino col mettere a fuoco il 'perchè' di un evento relativo al seguente programma /esempio che serve a listare sia tutti gli attributi relativi ad un’istanza di una sub classe, sia  quelli ereditati dalle super:

[codice]class ListInherited:
    def __str__(self):  # se qui sostituisco con __repr__   effettivamente looppa...
        return '<Istance of {}, address is {}, attribute:{}'.format(
                 self.__class__.__name__,
                 id(self),
                 self.__attrnames())
    def __attrnames(self):
        summa = ''
        for attr in dir(self):
            if attr[:2] == '__' and attr[-2:] == '__':
                summa += '\tname %s=<>\n' % attr
            else:
                summa += '\tname %s=%s\n' % (attr, getattr(self, attr))
        return summa
    
class Super:
    def __init__(self):
        self.data1 = 'attributo1'
    def ham(self):
        pass
    
class Sub(Super, ListInherited):
    def __init__(self):
        Super.__init__(self)
        self.data2 = 'attributo2'
        self.data3 = 'attributo3'
    def spam(self):
        pass
    

X = Sub()
print(X)[/codice]

Bene, se  sostituisco __str__ con __repr__  il codice loopa e mi da errore… ok, ma non ho capito ancora bene il perché…
Sicuramente non ho messo bene a fuoco la differenza tra  i due suddetti overloading operators, ma da quanto sto leggendo   la principale differenza è che __repr__ dovrebbe essere più specifico (un low-level display) e non ambiguo, a differenza di __str__ ; pertanto __repr__ dovrebbe dare informazioni in più (relativamente al codice)..però ancora non ho capito perché qui deve looppare …viene richiamato ricorsivamente ma non ho centrato il meccanismo di questo(cosa lo innesca?)..e a che ‘livello’ avviene…uffff
Grazie anticipatamente per l’illuminazione…

13
Base / problemino su gli Iteratori
« il: Marzo 31, 2012, 21:30 »
Ciao raga
allora a quanto pare ho un problema col concetto di 'iteratore' perchè me ne sto andando in palla su di un concetto che dovrebbe essere alquanto semplice...di seguito vi riporto l'esempio in questione (che in se per se servirebbe solo ad evidenziare come lavorano iteratori multipli su uno medesimo oggetto):

[codice]class SkipIterators:
    def __init__(self, wrapped):
        self.wrapped = wrapped
        self.offset = 0
    def __next__(self):
        if self.offset >= len(self.wrapped):
            raise StopIteration
        else:
            item = self.wrapped[self.offset]
            self.offset += 2
            return item
        
class SkipObject:
    def __init__(self, wrapped):
        self.wrapped = wrapped
    def __iter__(self):
        return SkipIterators(self.wrapped)
    
alpha = 'abcdef'
skipper = SkipObject(alpha)
I = iter(skipper)    #perche qui ho bisogno per forza di chiamare iter?
                    #la classe SkipObject non dovrebbe ritornare
                   #di per se un oggetto iteratore?
print(next(I), next(I), next(I))

for x in skipper:
    for y in skipper:
        print(x + y, end=' ')[/codice]

il problema( come riportato dal commento nel codice) è che non ho capito proprio perchè si deve chiamare iter sull'istanza 'skipper' della classe SkipObject per poter invocare next..
SkipObject, nella quale è già stato definito '__iter__ 'non dovrebbe già restituire un oggetto iteratore??(so che non lo fa dalla traceback, ma perchè? ... :confused:
Grazie anticipatamente

14
Scusatemi il ritardo nella presentazione  ;) infatti ho già usufruito del vostro supporto...
che dire... dopo una preparazione prettamente umanistica (laureato in sociologia) ho sentito il richiamo 'informatico"   :devil:
ci sono approdato tramite musica, che poi è diventata musica elettronica in "informatica"...appassionato di software musicali, sequencer, vst-plug in, sampler e virtual synth di ogni specie ;)...ma anche del web in genere (CMS, html,...); un giorno ho deciso di venire a vedere cosa c'è dietro tutto ciò  :D

15
Base / delucidazione su generatori
« il: Marzo 04, 2012, 22:54 »
Salve ragazzi
allora vi porto subito la funzione d'esempio relativa al mio dubbio :
[codice]def provaZip(*string):
    iters = list(map(iter, string))
    #for x in iters: print(list(x))
    while iters:
        com = [next(i) for i in iters]
        yield tuple(com)
           
X, Y = 'ken', 'abc123'
print(list(provaZip(X, Y)))[/codice]

allora non mi è  chiaro il perchè next dopo le tre iterazioni non da StopIteration..
si ok in questo caso yield evita il problema ma appunto non mi è molto chiaro 'il motivo'...  :dont-know:
quindi come mai yield restituisce il valore specificato esattamente dopo che next(i) ha concluso le iterazioni del caso presenti nella list comprehension  e senza riportare lo stop , in quanto while è ancora True!!.... :thinking:
grazie  anticipatamente...

Pagine: [1] 2