* Needs new category/file: Reverse Engineering Software @ 2016-02-17 14:38 Nils Gillmann 2016-02-17 22:35 ` Andreas Enge 0 siblings, 1 reply; 6+ messages in thread From: Nils Gillmann @ 2016-02-17 14:38 UTC (permalink / raw) To: guix-devel I see nothing in gnu/packages/ where I could put reverse engineering, disassembler tools. What I want to package is the disassember panopticon (https://panopticon.re) Existing: code.scm is a bit too generic for the specific purpose of panopticon debug.scm does not get the category right. As this doesn't do the job for me, I propose gnu/packages/disassembler.scm or gnu/packages/re.scm or gnu/packages/reverse-engineering.scm as it specifies an existing category of software and is not just another debugger. Additional thoughts: Reverse engineering typically makes use of Debuggers, Disassemblers, Hex Editors and PE and Resource Viewers. A new category could be used to cut down on category files maybe get some existing, non-specific software into the new created category. Other solution: use the new category only for software specifically developed for RE. What do you think? -- ng ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Needs new category/file: Reverse Engineering Software 2016-02-17 14:38 Needs new category/file: Reverse Engineering Software Nils Gillmann @ 2016-02-17 22:35 ` Andreas Enge 2016-02-18 14:33 ` Nils Gillmann 2016-02-18 14:45 ` Package modules Fabian Harfert 0 siblings, 2 replies; 6+ messages in thread From: Andreas Enge @ 2016-02-17 22:35 UTC (permalink / raw) To: Nils Gillmann; +Cc: guix-devel Hi Nils, On Wed, Feb 17, 2016 at 03:38:42PM +0100, Nils Gillmann wrote: > > As this doesn't do the job for me, I propose > gnu/packages/disassembler.scm > or > gnu/packages/re.scm > or > gnu/packages/reverse-engineering.scm > as it specifies an existing category of software and is not just > another debugger. the first and the last of these are fine; I would avoid "re" as it is not a word, and it is not clear at all what it is supposed to represent. > Reverse engineering typically makes use of Debuggers, > Disassemblers, Hex Editors and PE and Resource Viewers. A > new category could be used to cut down on category files maybe > get some existing, non-specific software into the new created > category. Do I understand correctly that you wish to move existing software into the new module (=file)? Why not if you do the work :-) Moving packages around is somewhat boring work and needs to be done carefully, since all the "use-module" clauses in files where the package is used need to be adapted. Andreas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Needs new category/file: Reverse Engineering Software 2016-02-17 22:35 ` Andreas Enge @ 2016-02-18 14:33 ` Nils Gillmann 2016-02-18 19:29 ` Andreas Enge 2016-02-18 14:45 ` Package modules Fabian Harfert 1 sibling, 1 reply; 6+ messages in thread From: Nils Gillmann @ 2016-02-18 14:33 UTC (permalink / raw) To: Andreas Enge; +Cc: guix-devel Andreas Enge <andreas@enge.fr> writes: > Hi Nils, > > On Wed, Feb 17, 2016 at 03:38:42PM +0100, Nils Gillmann wrote: >> >> As this doesn't do the job for me, I propose >> gnu/packages/disassembler.scm >> or >> gnu/packages/re.scm >> or >> gnu/packages/reverse-engineering.scm >> as it specifies an existing category of software and is not just >> another debugger. > > the first and the last of these are fine; I would avoid "re" as it is not > a word, and it is not clear at all what it is supposed to represent. Okay, understood. However, there's now the choice between a specific category (disassembler.scm) and a meta category (reverse-engineering.scm). Not having read every single line of the source of Guix yet, are meta-categories in general more welcome than specific categories? Reasons for meta would be that it's not limited to a specific category and serves more than one purpose. However, it will also be up to individuals to decide wether this is software typically used in the context of the name of the meta category. This might lead to further irritation for beginners. disassember.scm would give the specific instruction "put disassembler software inside me". I have not counted the number of debugging software, disassembler software, hex focused editors, PE and resource viewers in Guix sources. It might lead to a rather long file which centers on this topic. If I start disassembler.scm it has a one purpose, specific intention to just get disassemblers inside. If I start reverse-engineering.scm, it is open to moving specific sets of software inside. What are your thoughts on this? >> Reverse engineering typically makes use of Debuggers, >> Disassemblers, Hex Editors and PE and Resource Viewers. A >> new category could be used to cut down on category files maybe >> get some existing, non-specific software into the new created >> category. > > Do I understand correctly that you wish to move existing software into > the new module (=file)? Why not if you do the work :-) > Moving packages around is somewhat boring work and needs to be done > carefully, since all the "use-module" clauses in files where the package > is used need to be adapted. > See above, specifically last paragraphs. > Andreas > -- ng ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Needs new category/file: Reverse Engineering Software 2016-02-18 14:33 ` Nils Gillmann @ 2016-02-18 19:29 ` Andreas Enge 0 siblings, 0 replies; 6+ messages in thread From: Andreas Enge @ 2016-02-18 19:29 UTC (permalink / raw) To: Nils Gillmann; +Cc: guix-devel On Thu, Feb 18, 2016 at 03:33:23PM +0100, Nils Gillmann wrote: > Okay, understood. However, there's now the choice between a > specific category (disassembler.scm) and a meta category > (reverse-engineering.scm). > Not having read every single line of the source of Guix yet, are > meta-categories in general more welcome than specific categories? Well, this is a big mess in Guix, between modules for a single package (many of which dating back to when we started) up to python.scm containing everything python. Both are fine I think, feel free to make a choice! Andreas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Package modules 2016-02-17 22:35 ` Andreas Enge 2016-02-18 14:33 ` Nils Gillmann @ 2016-02-18 14:45 ` Fabian Harfert 2016-02-29 9:52 ` Ludovic Courtès 1 sibling, 1 reply; 6+ messages in thread From: Fabian Harfert @ 2016-02-18 14:45 UTC (permalink / raw) To: guix-devel Hi! I don't understand the point that makes package modules necessary in general and theoretically. We can have each package only once, so there's no need for that. I know that practically it is necessary because it's easy to structure and results from the definition of packages like program code. But why isn't it possible to include all the packages modules from (gnu packages) automatically? Is there something speaking against that? Fabian ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Package modules 2016-02-18 14:45 ` Package modules Fabian Harfert @ 2016-02-29 9:52 ` Ludovic Courtès 0 siblings, 0 replies; 6+ messages in thread From: Ludovic Courtès @ 2016-02-29 9:52 UTC (permalink / raw) To: Fabian Harfert; +Cc: guix-devel Fabian Harfert <fhmgufs@web.de> skribis: > I don't understand the point that makes package modules necessary in > general and theoretically. We can have each package only once, so > there's no need for that. > > I know that practically it is necessary because it's easy to structure > and results from the definition of packages like program code. Right. The thing to keep in mind is that “package modules” are just regular Scheme modules/libraries that export variables and import other modules. The advantage is that we get the semantics and all the functionality of Guile’s module system. The downside (the one you had in mind I guess?) is the boilerplate in each file. I think the advantages outweigh the disadvantages, though it would be cool if Guile supported a Racket-style #lang construct to help reduce boilerplate. > But why isn't it possible to include all the packages modules from (gnu > packages) automatically? Is there something speaking against that? Yes. For one, having control over which modules are imported allow you to make sure there are no name clashes, no ambiguities, and such. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-02-29 9:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-17 14:38 Needs new category/file: Reverse Engineering Software Nils Gillmann 2016-02-17 22:35 ` Andreas Enge 2016-02-18 14:33 ` Nils Gillmann 2016-02-18 19:29 ` Andreas Enge 2016-02-18 14:45 ` Package modules Fabian Harfert 2016-02-29 9:52 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).