Re: [GSoC 2017] Community Bonding
On 05/25/2017 09:27 PM, Umesh Singla wrote: > > About the project, so the `restore`, `snapshot` and `migrate` actions > > are going to the action_array list [1]. While the flow was made clear > > in the proposal, I think the first step should be to decide on an > > exhaustive list of arguments/flags these 3 actions can possibly take. > > This will help to design the procedures. > > > > Also, should we keep the code in a different Tcl script migrate.tcl > > like `reclaim`? > > I would prefer that, yes. You'll just need > package provides macports 1.0 > line at the top and then you can write code as if it was in > macports.tcl. Alternatively, you can do what reclaim.tcl does and use > package provides migrate 1.0 > and add 'package require migrate 1.0' in macports.tcl. > > > Since we are planning on 3 different actions which can also be used > independently like snapshot and migrate, having 2 scripts in the macports1.0 > directory directly or keeping these 2 commands in a single script doesn't seem > to be good from design pov. We can have a separate folder for new (upcoming) > actions with a hope that the existing code be split into "action" modules over > the time. Not sure what you mean with "a new folder" here. The macports 1.0 package is the public MacPorts API. Every feature should be reachable from there. If you think separate files make more sense, split them into multiple files (as done with reclaim.tcl or diagnose.tcl). It sounds logical to me to keep snapshot and restore together, since they will export to/import from the same data format. Migrate could be in its own file. As a side note, while 'port migrate' seems important enough for a new port action, aren't the former two only useful together? Then I would expect the functionality in the same port action, such as for example: port snapshot --create port snapshot --restore > Yes, the testing is not trivial at all. It might make sense to work with > mocking a lot here (e.g. overwrite functions that would usually be > called by your code to do nothing). That would allow you to run tests > without actually changing your system or doing a lot of environment > setup. > > Fortunately Tcl makes this quite easy because you can change any > function definition at runtime. > > > Is there anything even sacred to Tcl? Till now, it looks like you can just use > anything in the language with pretty much anything else. This calls for a new > blog post. And planning to discuss on the testing part in next email. > > Also, can we have a small README with two to three lines kept in every folder > in > the base code at least? That'll be actually very helpful. I am not convinced separate README files make sense instead of a single consolidated documentation at one place. If I do not know where something is implemented, how would I find the correct directory with the README to look at? A single document seems easier to search and skim through to understand the structure. Developer documentation is somewhat shattered across multiple places. Some information and pointers to the wiki are in HACKING at the top-level, while other stuff is also in the guide [1]. If unsure, about anything please just ask. [1] https://guide.macports.org/#internals > Also, I tried StackOverflow but does tclsh support all bash commands? There are different modes in which tclsh can be used. In interactive mode, tclsh will fall back and call external binaries when no proc or builtin exists with the name of the command you tried to run. This is similar to the behavior of normal shells like bash. However, this will not happen in non-interactive use, i.e. when interpreting a script (as in running the port(1) command). Rainer
Re: [GSoC 2017] Community Bonding
Hi > > About the project, so the `restore`, `snapshot` and `migrate` actions > > are going to the action_array list [1]. While the flow was made clear > > in the proposal, I think the first step should be to decide on an > > exhaustive list of arguments/flags these 3 actions can possibly take. > > This will help to design the procedures. > > > > Also, should we keep the code in a different Tcl script migrate.tcl > > like `reclaim`? > > I would prefer that, yes. You'll just need > package provides macports 1.0 > line at the top and then you can write code as if it was in > macports.tcl. Alternatively, you can do what reclaim.tcl does and use > package provides migrate 1.0 > and add 'package require migrate 1.0' in macports.tcl. > > Since we are planning on 3 different actions which can also be used independently like snapshot and migrate, having 2 scripts in the macports1.0 directory directly or keeping these 2 commands in a single script doesn't seem to be good from design pov. We can have a separate folder for new (upcoming) actions with a hope that the existing code be split into "action" modules over the time. > > If you need any additional special SQL queries, that can be done, yes. > There should be abstractions available in Tcl already so that you don't > have to deal with SQLite's C API directly, though. > > The cregistry folder seems to have most of the sql queries implemented and to deal with the registry database, I'll only have create, update and select queries to do, so looks like I won't have to deal with C. I went through an entire "port uninstall" example to see how from Tcl gets to sqlite C through registry, so things seem a bit clear than before. > > Yes, the testing is not trivial at all. It might make sense to work with > mocking a lot here (e.g. overwrite functions that would usually be > called by your code to do nothing). That would allow you to run tests > without actually changing your system or doing a lot of environment > setup. > > Fortunately Tcl makes this quite easy because you can change any > function definition at runtime. Is there anything even sacred to Tcl? Till now, it looks like you can just use anything in the language with pretty much anything else. This calls for a new blog post. And planning to discuss on the testing part in next email. Also, can we have a small README with two to three lines kept in every folder in the base code at least? That'll be actually very helpful. As Clemens suggested on IRC, will start with an *honest* short daily log of the work like what I did for the project and what I did related to MP etc from today onwards. Also, I tried StackOverflow but does tclsh support all bash commands? Regards, Umesh Singla
Buildbot emails
Dear Ryan, In case you have time, can you please check again where the buildbot email reports get lost? Thank you, Mojca
Re: Port hanging (unresponsive to Ctrl+C, need SIGKILL)
On 2017-05-24 23:47, Clemens Lang wrote: I've previously seen builds using xcodebuild in particular hanging after they were apparently done. In the cases I've seen so far xcodebuild eventually terminated itself after quite a bit of time. Did you try sending the kill signal to the xcodebuild process only, or was that already terminated at this point? It's already terminated. This is the process that remains: 91761 macports /opt/local/libexec/macports/bin/tclsh8.5 /opt/local/bin/port -d install +logo I can see a single child under it: 91820 macports (sh) I cannot kill process 91820, even with sudo kill -9. I just noticed now that if I'm patient and I wait long enough (~3 minutes), the build actually "recovers" and continues. I'm a bit lost here. The upstream shell build script, which runs a virtually identical `xcodebuild` command as this port, does not exhibit this behaviour. I can provide build logs. I did not attach them here since I'm not sure if it is regular practice to send attachments to the list. Any help would be much appreciated, // Leonardo.
