Re: blip 0.5
On 11/18/10 1:12 AM, Bill Baxter wrote: Nice work! Is it for D2 or D1? Or both? --bb I hope you don't mind me answering, Fawzi: Currently, it's D1 only.
Re: blip 0.5
Nice work! Is it for D2 or D1? Or both? --bb On Wed, Nov 17, 2010 at 2:42 PM, Fawzi Mohamed wrote: > I am happy to announce blip 0.5 > >http://dsource.org/projects/blip > > why 0.5? because it works for me, but hopefully it will work for others > too, and 1.0 will be a release with more contributors... > > Blip is a library that offers > > * N-dimensional arrays (blip.narray) that have a nice interface to lapack > (that leverages the wrappers of baxissimo) > * 2,3 and 4D vectors, matrixes and quaternions from the omg library of > h3r3tic > * multidimensional arrays, with nice to use wrappers to blas/lapack > * a testing framework that can cope both with combinatorial and random > testing > this means that you can define an environment (be it struct or class, > maybe even templatized) > and then define generators that create one such environment (see > blip.rtest.BasicGenerators) > then you can define testing functions that will receive newly generated > environments and do the tests > * serialization (blip.serialization) that supports both json format, that > can be used also for input files and an > efficient binary representation > * MPI parallelization built on the top of mpi, but abstracting it away (so > that a pure tcp implementation is possible), > for tightly coupled parallelization > * a Distribued Objects framework that does rpc via proxies > (blip.parallel.rpc) > * a simple socket library that can be used to connect external programs, > even if written in fortran or C (for a weak parallel coupling) > * a coherent and efficient io abstraction > > But what might be most interesting is. > > * SMP parallelization (blip.parallel.smp) a numa aware very flexible > framework > > a parallelization framework that can cope well with both thread like and > data like parallelism, integrated with libev > to offer efficient socket i/o and much more. > > An overview of blip is given in >http://dsource.org/projects/blip/wiki/BlipOverview > The parallelization is discussed in >http://dsource.org/projects/blip/wiki/ParallelizationConcepts > finally to install it see >http://dsource.org/projects/blip/wiki/GettingStarted > > enjoy > > Fawzi >
Re: [OT] DVCS
On 11/17/10 10:27 PM, "Jérôme M. Berger" wrote: […]It might be possible to change the configuration so that this won't happen, but the simple fact that this happens with the *default* config does not fill me with confidence regarding data integrity and Git... This is not exactly true, at least not for the Git on Windows installer, which presents you with the three possible choices for handling line endings. Also, I am not quite sure if this deserves the label »data corruption«, because even if you have auto-conversion of line endings turned on and Git fails to auto-detect a file as binary, no history data is corrupted and you can fix the problem by just switching off auto-conversion (either globally or just for the file in question via gitattributes) – in contrast to actual history/database corruption.
blip 0.5
I am happy to announce blip 0.5 http://dsource.org/projects/blip why 0.5? because it works for me, but hopefully it will work for others too, and 1.0 will be a release with more contributors... Blip is a library that offers * N-dimensional arrays (blip.narray) that have a nice interface to lapack (that leverages the wrappers of baxissimo) * 2,3 and 4D vectors, matrixes and quaternions from the omg library of h3r3tic * multidimensional arrays, with nice to use wrappers to blas/lapack * a testing framework that can cope both with combinatorial and random testing this means that you can define an environment (be it struct or class, maybe even templatized) and then define generators that create one such environment (see blip.rtest.BasicGenerators) then you can define testing functions that will receive newly generated environments and do the tests * serialization (blip.serialization) that supports both json format, that can be used also for input files and an efficient binary representation * MPI parallelization built on the top of mpi, but abstracting it away (so that a pure tcp implementation is possible), for tightly coupled parallelization * a Distribued Objects framework that does rpc via proxies (blip.parallel.rpc) * a simple socket library that can be used to connect external programs, even if written in fortran or C (for a weak parallel coupling) * a coherent and efficient io abstraction But what might be most interesting is. * SMP parallelization (blip.parallel.smp) a numa aware very flexible framework a parallelization framework that can cope well with both thread like and data like parallelism, integrated with libev to offer efficient socket i/o and much more. An overview of blip is given in http://dsource.org/projects/blip/wiki/BlipOverview The parallelization is discussed in http://dsource.org/projects/blip/wiki/ParallelizationConcepts finally to install it see http://dsource.org/projects/blip/wiki/GettingStarted enjoy Fawzi
Re: [OT] DVCS
On 11/17/10 10:32 PM, "Jérôme M. Berger" wrote: […] you are not forced into this model when you know you have only worked on a single feature and want to commit it. You are not forced to use the staging area with Git either (although most of the developers I know do use it), it's just the default that is different. If you want to save the extra characters per commit, just add an alias like »ci = commit -a« to your ~/.gitconfig, just like you might want to use »nudge = push --rev .« with Mercurial…
Re: [OT] DVCS
Alexey Khmara wrote: > "add + commit" is not a bad design at all. It is just design choice, > and it also about "patch control system", that allows more logical > commit history and more precise control over VCS. It allows to code > all things you want and place into commit only part of your changes. > You even can stage part of file - if, for example, you done two > logically different changes without commit between them. May be, good > analogy will be reading file with one command versus "open-read-close" > sequence - simplicity versus good control. > > This feature allows very comfortable, free coding style - you write > what you want ad understand now, and later you can divide your changes > to logically related sets. You do not controlled by limits imposed by > VCS - "work on one feature, commit, work on another". Instead VCS > works in your style and rhythm. Usually you don't want run "commit > -a". Instead when you run "git status" you see several files that you > do not want to commit right now. So you use "add + commit" sequence, > may be - several times to commit different changesets as distinct > entities with distinct comments. > > I think it's very good point of view - to track not file versions, > patchsets that represent something meaningful - new features, bugfixes > etc, and have VCS follow your practices and rhythm - and have > understandable version tree at the end. This has nothing to do with Git's staging area. Mercurial also tracks patchsets that represent something meaningful and has full support for partial commits (with record or crecord) so you can "write what you want and understand now, and later [...] divide your changes to logically related sets". On the other hand, you are not forced into this model when you know you have only worked on a single feature and want to commit it. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [OT] DVCS
Bruno Medeiros wrote: > But what exactly is that data corruption issue on Windows? > In some cases (I didn't try to isolate the precise conditions), Git will replace '\n' with '\r\n' in binary files. This is with the default config. It might be possible to change the configuration so that this won't happen, but the simple fact that this happens with the *default* config does not fill me with confidence regarding data integrity and Git... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: DDT 0.4.0 released (formerly "Mmrnmhrm")
Looking pretty good so far!
Re: [OT] DVCS
"add + commit" is not a bad design at all. It is just design choice, and it also about "patch control system", that allows more logical commit history and more precise control over VCS. It allows to code all things you want and place into commit only part of your changes. You even can stage part of file - if, for example, you done two logically different changes without commit between them. May be, good analogy will be reading file with one command versus "open-read-close" sequence - simplicity versus good control. This feature allows very comfortable, free coding style - you write what you want ad understand now, and later you can divide your changes to logically related sets. You do not controlled by limits imposed by VCS - "work on one feature, commit, work on another". Instead VCS works in your style and rhythm. Usually you don't want run "commit -a". Instead when you run "git status" you see several files that you do not want to commit right now. So you use "add + commit" sequence, may be - several times to commit different changesets as distinct entities with distinct comments. I think it's very good point of view - to track not file versions, patchsets that represent something meaningful - new features, bugfixes etc, and have VCS follow your practices and rhythm - and have understandable version tree at the end.
Re: Utah Valley University teaches D (using TDPL)
bearophile wrote: > Lutger Blijdestijn: > >> Actually the unix convention is to give exit code 0 as an indicator of >> success, so there is feedback. It is very usable for scripting. > > But currently something like that is not present in the D unittest system. rdmd --main -unittest somemodule.d
Re: TDPL in Russian
On 15/11/2010 12:27, Adrian Matoga wrote: I wish you will be given a translation of the same quality, TDPL is worth it. What do you mean by this? You mean a Portuguese translation? -- Bruno Medeiros - Software Engineer
Re: [OT] DVCS
On 13/11/2010 11:24, "Jérôme M. Berger" wrote: Bruno Medeiros wrote: Well, yes, it is every-times with regards to having to add the extra commit option. But it is just 3 extra characters, and I'm guessing it is quite easy to remember every time (maybe a little bit less if you use different VCS often, yeah). I'm not saying git would not be better designed if " -a" was the default, just that it's a very unimportant in terms of comparing VCS's. (It matters even less to my usage of VCS, since almost always I use Eclipse's graphical interface, which has a common behavior for the basic operations in all popular VCS. :) ) Like I said, it is a pretty minor issue in and of itself. Its importance is as a symptom of how poorly designed the interface is in general. My main objections to Git are in order of importance: 1. Data corruption on Windows. That one is the killer issue; 2. Poor interface by design! The "-a" option is in this category, but it is not the only issue there by far. Most of those issues taken individually would be pretty minor, but added together they make Git very uncomfortable to work with; 3. Git is not a VCS so much as a PMS (Patch Management System). The difference is in the way each views history: for a VCS, history is important in and of itself, whereas for a PMS like Git history is just something you keep to help you merge branches. Git's much touted history rewriting abilities are more a liability than an asset for a VCS. In a roundabout way, this is why most Git users view the "-a" issue as negligible: if you forget part of a commit, just commit the missing changes and collapse the two changesets (which is easy since we don't care about history anyway). Points 1 and 2 are real issues. That is, they are intrinsically negative points. Point 3 is more a difference between Git and everything else, so it will be negative or neutral (*) depending on what exactly you expect from a SCM. Jerome (*) I wrote "neutral" instead of "positive", because IMO Mercurial offers similar abilities as a PMS if that is all you want. Hum, thanks, this post was quite informative. But what exactly is that data corruption issue on Windows? -- Bruno Medeiros - Software Engineer
DDT 0.4.0 released (formerly "Mmrnmhrm")
I'm announcing the release of DDT (D Development Tools) version 0.4.0: http://code.google.com/a/eclipselabs.org/p/ddt/ (There was previously an older inactive project also called DDT, it has been renamed to EclipseD, with the authors permission.) The DDT project is a direct continuation of the Mmrnmhrm project. It has been renamed to reflect a more serious and unified approach to the Eclipse IDE project development. (although ocasional odd references might still be present in less conspicuous places ^_^ ) It has been 2 years since the last significant release, and this version has a lot of rough edges: Some newer D2 syntaxes are not yet supported (http://code.google.com/a/eclipselabs.org/p/ddt/issues/detail?id=6), and otherwise there are likely to be several parser bugs in the IDE (... you will be baked...). But it should provide for a minimally useful IDE, at least for simpler D projects. See http://code.google.com/a/eclipselabs.org/p/ddt/wiki/Features for a rough idea of what to expect. See also: http://code.google.com/a/eclipselabs.org/p/ddt/wiki/GeneralFAQ Changelog: == DDT 0.4.0 (2010-11-17) == * Renamed project to DDT * Updated IDE to latest DLTK version (2.0). * Fixed comment indentation character (was '#' instead of '//') on toggle comment actions * Fixed defaults bug in DeeRootPreferencePage and DeeEditorPreferencePage. * Added DEEBUILDER.COMPILEREXEPATH variable to builder, changed builder response file defaults. [No longer uses rebuild as the default] * Fixed parser to be able to parse expressions as the argument of typeid. * Added a parser workaround to allow parsing D source with annotations. * Fixed several parser bugs. * Removed Content Assist Templates preference page. -- Bruno Medeiros - Software Engineer
Re: Utah Valley University teaches D (using TDPL)
Lutger Blijdestijn: > Actually the unix convention is to give exit code 0 as an indicator of > success, so there is feedback. It is very usable for scripting. But currently something like that is not present in the D unittest system. > But with the > change Sean suggested - and I assume an extension point in druntime - there > would be enough for a more human friendly tool to be built on top of the > current D unittesting system. We'll see. Bye, bearophile
Re: Utah Valley University teaches D (using TDPL)
bearophile wrote:
> Jonathan M Davis:
>
>> Most of the rest (if not all of it) could indeed be done in a library.
>
> I am not sure it could be done nicely too :-)
>
>
>> Right now
>> unit tests follow the unix convention of saying nothing on success,
>
> That's an usability failure. Humans expect feedback, because you can't
> tell apart "unittests run and succeed" from "unittests not even run". That
> Unix convention is bad here. And Unix commands sometimes have a -v
> (verbose) command that gives feedback, while D unittests don't have this
> option.
Actually the unix convention is to give exit code 0 as an indicator of
success, so there is feedback. It is very usable for scripting. But with the
change Sean suggested - and I assume an extension point in druntime - there
would be enough for a more human friendly tool to be built on top of the
current D unittesting system.
>> particularly when it's not all that hard
>> to add code yourself which prints out success if you really want it to.
>
> It's also not hard to define global functions, wrapped in a
> version(unittest){}, to replace the need of the unittest keyword (unittest
> becomes a version ID).
>
> Bye,
> bearophile
