# Dumb idea on git library for script languages 5 messages from 2008-04-28 to 2008-04-29. Participants: tsgates, Jakub Narebski, Johannes Schindelin, Eric Hanchrow, Govind Salinas. Thread: https://gitlist.dev/t/13302 ## tsgates, 2008-04-28 07:03 Subject: Dumb idea on git library for script languages Message-ID: <1209366216.17090.4.camel@prosumer> URL: https://gitlist.dev/e/1209366216.17090.4.camel%40prosumer ``` Please comment on my naive idea. When I try to use git in python, there are no fancy ways not to fork any processes. (except not active git library) I know it is design policy of git, one job for one process. Anyhow, I need to call git in python and perl, so I try to think. I assumed that 1. all cmd_*() is designed in a process basis, so it is ok to free all memories which invoked after calling cmd_*() 2. result of cmd_*() is output only so parse it in order to use in script language right before call cmd_*() -> redirect stdout to anything 3. 'die()' can be escaped by using "setjmp/longjmp" 4. actually I need only cmd_*() or little low level functions from script here is snippets of naive pseudo codes ------------------------------------------------------------ # will be called from the python/perl code ------------------------------------------------------------ lib_git_do() { if ( setjmp( exterend here ) ) { start_trace() cmd_do() stop_trace() } else { # called from die (from longjmp) return error occured } return parse_do(); } ------------------------------------------------------------ start_trace() { init_mem() start_malloc_trace() start_stdout_trace() } stop_trace() { stop_stdout_trace() stop_malloc_trace() clean_mem() } start_malloc_trace() { hook __malloc_hook hook __realloc_hook hook __free_hook } malloc_hook( size ) { void * rtn = malloc( size ) if ( rtn ) { add_to_mem_record( thread_id, rtn ) } } free_hook( ptr ) { if ( free( ptr ) ) { del_mem_record( thread_id, ptr ) } } clean_mem() { for_each ( mem_records ) free( ptr ) } ------------------------------------------------------------ pros 0. easy to implement 1. guarantee thread safety 2. no memory leak 3. not depend on git source 4. able to take advantage of script codes, no forking overhead cons 0. not fancy 1. need dumb parsing 2. just temporary solution but, I want to use it in review board or track like system, right now. If there are any other good suggestions or recommendations on it, please recommend it. Best regards ``` ## Jakub Narebski, 2008-04-28 07:31 Subject: Re: Dumb idea on git library for script languages Message-ID: URL: https://gitlist.dev/e/m38wyyphai.fsf%40localhost.localdomain In-Reply-To: <1209366216.17090.4.camel@prosumer> ``` tsgates writes: > When I try to use git in python, there are no fancy ways not to fork any > processes. (except not active git library) I know it is design policy > of git, one job for one process. > > Anyhow, I need to call git in python and perl, so I try to think. [...] > If there are any other good suggestions or recommendations on it, please > recommend it. Please take a look at libgit-thin project, which was Google Summer of Code 2007 project; it was meant to create PyGit, git bindings for Python. I don't know how far it is/got advanced. InterfacesFrontendsAndTools page on Git Wiki mentions it. -- Jakub Narebski Poland ShadeHawk on #git ``` ## Johannes Schindelin, 2008-04-28 10:28 Subject: Re: Dumb idea on git library for script languages Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0804281125330.5399%40eeepc-johanness In-Reply-To: <1209366216.17090.4.camel@prosumer> ``` Hi, On Mon, 28 Apr 2008, tsgates wrote: > malloc_hook( size ) { > void * rtn = malloc( size ) > if ( rtn ) { > add_to_mem_record( thread_id, rtn ) > } > } > > free_hook( ptr ) { > if ( free( ptr ) ) { > del_mem_record( thread_id, ptr ) > } > } > > clean_mem() { > for_each ( mem_records ) > free( ptr ) > } This is not enough. We have quite some static variables which point directly or indirectly to these allocated regions. I think you'd need to implement some resetter functions if you were to libify libgit.a. The easier way would definitely be to go with libgit-thin, as Jakub suggested. Ciao, Dscho ``` ## Eric Hanchrow, 2008-04-29 04:06 Subject: Re: Dumb idea on git library for script languages Message-ID: <873ap5484n.fsf@offby1.atm01.sea.blarg.net> URL: https://gitlist.dev/e/873ap5484n.fsf%40offby1.atm01.sea.blarg.net In-Reply-To: <1209366216.17090.4.camel@prosumer> ``` Look into Python's "subprocess" module; it has all you need to cleanly invoke subprocesses, capture their output, and check their return status. -- It has been suggested that this article or section be merged into Fried dough. (Discuss) -- Seen on Wikipedia ``` ## Govind Salinas, 2008-04-29 04:25 Subject: Re: Dumb idea on git library for script languages Message-ID: <5d46db230804282125g41be08a1v1d41155fe2305dac@mail.gmail.com> URL: https://gitlist.dev/e/5d46db230804282125g41be08a1v1d41155fe2305dac%40mail.gmail.com In-Reply-To: <1209366216.17090.4.camel@prosumer> ``` On Mon, Apr 28, 2008 at 2:03 AM, tsgates wrote: > Please comment on my naive idea. > > When I try to use git in python, there are no fancy ways not to fork any > processes. (except not active git library) I know it is design policy > of git, one job for one process. > > Anyhow, I need to call git in python and perl, so I try to think. > You may be interested in Pyrite, which has a Repo class that you may find helpful. It is a work in progress, so there are probably bugs, but I would be interested in fixing them. You can find it here http://gitorious.org/projects/pyrite Eventually, I plan to use libgit (or libgit-thin depending on what is appropriate) instead of subprocesses, but that is in the future. -Govind ```