Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2017-03-30

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:24 mizu_no_oto joined #darcs
01:11 dolio joined #darcs
01:48 ilbot3 joined #darcs
01:48 Topic for #darcs is now http://darcs.net/ | logs: http://irclog.perlgeek.de/darcs/ | darcs 2.12.5 is out http://darcs.net/Releases/2.12
02:26 Riastradh joined #darcs
03:58 mizu_no_oto joined #darcs
04:41 mal`` joined #darcs
04:47 maerwald joined #darcs
06:48 bfrk joined #darcs
06:51 bfrk Hi. I want to introduce an operator (?) as a synonym for parseFlags. This gives much nicer syntax when querying option values e.g. "withRepoLock (dryRun ? opts) (useCache ? opts) ..."
06:52 bfrk Any stong objections?
06:52 bfrk s/stong/strong/
07:00 Mysterious joined #darcs
07:09 bfrk joined #darcs
07:10 bfrk Heffalump: are you there?
07:19 bfrk ok will come back later
08:06 Mysterious Hello. I've learned about darcs a week ago and now I'm trying to use it with my home projects. I am in search of a collection of «the best practices in darcs», including cases of branching, merging, team work etc. What should I read first?
08:06 Mysterious I've noticed that many pages on the site SO and other people reffer to are not available. Were they renamed or removed? Does it mean darcs docs are not developing?
08:08 Mysterious Particularly, I am interesting in spontaneous branches mentioned in many places
08:16 lelit Mysterious_Light: with darcs, the concepts of "branch" and "merge" are somewhat marginal: basically, a darcs repo is "simply" a set of patches, so a "branch" is basically a repo with either a subset or a superset of the patches contained by another one
08:17 lelit you do a "merge" pulling in new patches not already contained by the repo
08:19 lelit this is the main distinct characteristic of how darcs works compared to, say, git: if you have two patches, one creating file A, the other creating file B, under darcs it does not matter in which order you apply them, whereas under git you have two different branches representing A+B and B+a
08:20 lelit s/+a/+A
08:36 Mysterious_Light I see. However, as far as "branching" is an important part of a workflow, all the practices under the patch theory and darcs must be declared. That is why I am so interested in stories "given a situation context, I do this, I do that, I achieve the result I want, you might do the same"
08:38 Mysterious_Light Let's consider another case based on what you've said. I have one patch (A) creating A, the second one (B) creating B and the third (T) considerably modifying both of them. I want to rollback (git's checkout) to AB and continue writing patches starting with a domain context BA0 (0 is an initial context, I hope I use correct notation). When needed, I want to merge T: AB0→TAB0 with new patches CDE…: BA0→…EDCBA0. Can I do
08:46 lelit darcs will either figure out a way to add T (that is, it knows that T is built on top of AB), or will spit a conflict you shall resolve (and commit as, say, T')
08:57 ThomasLocke joined #darcs
08:58 Mysterious_Light Yes, it's exactly what I want. How to get it? According to "a "branch" is basically a repo", after commiting A and B I can clone the repo, commit T to the first one and use the second one for my further dev. My question is whether that practice is natural for darcs or I am doing wrong an there is an easier way.
09:00 lelit I think it's easier to do than to explain it :-)
09:01 lelit you can just keep going in the same repo
09:02 lelit whenever you actually need to write a patch that *does not* depend on T, you can clone the repo and *unpull* T
09:04 lelit as another way, assuming that you new X patch effectively does not depend on T, at "darcs push" time you say "No" when it asks whether it should push the X patch
09:04 lelit and you are done
09:06 lelit you really must start thinking at your patches as the first class citizens of your repos, instead of thinking the latter as a states snapshot container
09:21 ThomasLocke I'm a new darcs user and also horrible at spelling. How do I fix my spelling mistakes in my commit messages? I usually detect them after the fact. Yea I know I'm an idiot.  :D
09:26 lelit provided you didn't already push the patches, "darcs amend --help"
09:27 ThomasLocke So simple. Thanks lelit
09:27 lelit do not do that if the assumption is false
09:27 lelit in git parlance, it would be like pushing a rebase over an existing repo
09:27 ThomasLocke I'm well aware of my horribly spelling, so I try to avoid pushing too fast.  :D
09:27 lelit :)
09:29 pointfree[m] joined #darcs
09:34 Mysterious_Light joined #darcs
09:34 Mysterious_Light Yeah, I have some difficulties when trying to do something more complicated that pull-commit-push loop. Now I just want to clearify what we've discussed.
09:35 Mysterious_Light I know that darcs determines the earliest context in the patch chain the reconding patch can be applied to. That is the reason why A and B in you example use the same domain context. I also know that one can select manualy all the patches the commiting patch depends on, with --ask-dep.
09:35 Mysterious_Light Let T be a patch with some domain context a and C be another patch with the same domain I will write later. I want use the working directory that was before T while writing C.
09:36 Mysterious_Light As I understant, the first way is to clone the entire repo without T. When some patch (say, C) is made, I can merge two repos with or without comflicts depending on CvT.
09:36 Mysterious_Light The second way is "darcs rollback" which creates an inverse patch to T. Now both T and T^{-1} are in the patch chain of my repo and I can add some more patches (say, C) after them. Can I merge new patches with rollbacked T? Should I rebase …TT^{-1}C to …CT (I have no idea how to do it)? Or auxiliary repo is required?
09:39 lelit I have some problem imagining your use case, but no, I don't think that rollback is the way to go, you'd pollute your repo without a reason (I can see from here)
09:44 lelit also, --ask-dep is rarely needed (I think I used it once or twice...): its main use case is when darcs has no enough information to establish a dependency between two commits
09:47 lelit for example, commit A added a "#define MAX_NUM 1000" to "header.h", and commit B uses that define in "source.c": darcs has no way to see that B must be applied only after A (that is, applying B without A would generate an un-compilable situation)
09:48 lelit in that case, when you register B, you can tell darcs about that using --ask-dep
09:48 Mysterious_Light For example, T changes some configs, turns off debuging logs etc. When coding, restricted version is more convenient than full one. When "merging dev to testing/master branch", all these supplimentary things must be cleaned.
09:48 lelit if you do that, should you unpull A, darcs would also unpull B
09:50 Mysterious_Light Also, I consider patches to be arrows in the category of patches. Effective linearity in darcs' repo is really confusing me.
09:50 lelit I would explicitly name T with something like "[dev-only]" and omit that patch when pushing into the production repo
09:53 Mysterious_Light i.e. you prefer to name "logical branch" a patch belongs to as a part of a message string?
09:58 lelit as said, I do not think in term of "branches" when working with darcs, but rather as "functionalities": a particular functionality (not necessarily implemented by a single patch) is either "acceptable" in production or it is not
09:58 lelit to make another practical example: I used to keep my .emacs.d under darcs, exchanging patches with coworkers
10:00 lelit not all of them are "acceptable" in my own .emacs.d, maybe because they change their own user-mail-address, and it obviously does not make any sense for to use their setting
10:00 lelit when I pull the changes, I skip those that I do not want
10:02 lelit but when they improve something, adding a new feature, then of course I'm really interested and happily pull those changes into my own .emacs.d
10:12 Mysterious_Light thank you
10:18 qwebirc877 joined #darcs
10:19 lelit somewhat related, see http://bugs.darcs.net/issue555 and https://pijul.org/2016/02/15/branches.html
10:58 pem__ lelit: or try branches in Pijul! Forking is O(log n), with n the size of history.
10:59 lelit pem__: sooner or later I'll surely do, thank you
11:00 lelit I'm following pijul evolution, but still as lurker :)
11:06 pem__ lelit: I still use darcs a lot, actually. For projects where I cannot afford to be distracted by bugs (like papers with coauthors), and for the nest, where fixing the nest is often more urgent than fixing pijul. Also, there is no "pijul dist" yet, which is how the nest is compiled
11:24 ML_ joined #darcs
11:25 qwebirc159035 joined #darcs
12:12 pointfree The darcsden user feeds work, but I'm thinking about organizing the database fields around some parts of a natural language sentence. It's easier to think it through now than to update the database document structure later.
12:13 pointfree Here are some fictional sentences that could appear in a user feed: http://hub.darcs.net/pointfree/feed-sentences/browse/README.md
12:13 pointfree Can anyone think of others they might want?
12:14 pointfree It's fairly easy to add new news feed event types.
12:16 pointfree ...but it's harder to generate some of them retroactively.
12:59 pointfree Heffalump: Just stumbled upon this http://hub.darcs.net/ganesh/darcsden-abstractcouch and it looks interesting. Much leaner code without the code duplication. What would it take for it to be mergeable?
13:52 Heffalump pointfree: I thought that was merged now
13:57 leg joined #darcs
14:19 pointfree Heffalump: Hm. Maybe it was and I didn't notice because complexity was added since then.
15:45 gh_ joined #darcs
15:52 bfrk apropos complexity: can I remove the --remote-repos option? this would help a lot as it causes numerous ugly work-arounds (i can explain in detail if necessary). And it adds zero functionality since it is just an alternative notation for giving the remote repos as normal (non-option) arguments.
15:57 bfrk Heffalump, gh_: ping
15:58 gh_ bfrk, hi (I was reading the on-line IRC logs to see whether you said more before I entered)
15:59 gh_ bfrk, wouldn't removing this flag make it harder to call darcs commands through libdarcs?
16:00 gh_ bfrk, an example would be nice
16:02 bfrk gh_: calling through libdarcs is much easier with normal arguments than with options: you can just pass them in a list
16:05 bfrk an example where it hurts badly is http://hub.darcs.net/darcs/darcs-screened/browse/src/Darcs/UI/RunCommand.hs#147
16:14 sm how would I find the --remote-repos option
16:14 bfrk gh_: re libdarcs: we currently treat flags and normal arguments in a different way: for normal arguments, things like converting local paths absolute paths is done inside the command implementation, whereas for flags this is done before the command is called.
16:16 sm (or did you mean --remote-repo  ?)
16:16 bfrk sm: I think it is actually named --remote-repo=REPO and can be given more than once
16:16 bfrk (so: yes)
16:17 sm yes I see. (Confirmed by searching the output of darcs help markdown)
16:19 bfrk sm: the option is defined (as all options are, except matching options) in http://hub.darcs.net/darcs/darcs-screened/browse/src/Darcs/UI/Options/All.hs#514
16:22 * sm wonders why it was added
16:24 sm I see remoteRepos was added by your "integrate new options subsystem" patch in 2014. I wonder how to annotate back before that
16:24 bfrk sm: perhaps at some point the idea was to eliminate the handling of normal arguments from the command implementations; that is, normal arguments are converted to suitable options before calling the command.
16:26 * sm reads about it at http://darcs.net/manual/Darcs_commands.html .. pretty unclear
16:26 bfrk sm: no, no, I merely moved things around. I found the patch with darcs log -premote-repo
16:26 bfrk it was by Eric Kow IRRC
16:26 bfrk in 2008
16:28 Heffalump bfrk: around now, but travelling (and hence will have tunnels)
16:28 Heffalump FWIW I had no idea about the --remote-repos option, please use your own best judgement on it.
16:29 sm sounds like a misfeature, if none of us know what it's for
16:45 bfrk sm: yeah that was what I thought. The original plan I mentioned above (if there ever was such a plan) isn't that bad, in principle. But if we want to do that, we should do it for *all* kinds of normal arguments. That would mean new options for: files (in and out of the repo), pref names, etc. And then we'd have to decide how and where to do all the "fixing" (conversion of argument paths to subpaths of the repo). Possible, but not for the faint-hear
16:47 bfrk (I'll be back in a few minutes)
16:47 * sm hands bfrk a stout axe
16:55 pointfree sm: It looks like there are a number of knobs to turn for getting better performance out of couchdb, and we're not really twiddling any of them.
16:55 pointfree http://guide.couchdb.org/draft/performance.html
16:55 pointfree I hear that having a lot of CouchDB views is bad for performance. My implementation of darcsden user feeds uses a by_subscriber view.
16:55 pointfree http://stackoverflow.com/a/35528961/44016    <--- now I know that it may be a good idea to have a design document for each user, or wherever things can partitioned.
16:55 pointfree btw, sm, are you compacting the CouchDB database? iirc, you have backups of the darcshub data anyway although maybe not as fine-grained. I don't know what your darcshub backup system is like.
16:55 pointfree are you doing backups with the CouchDB replication feature?
16:58 sm pointfree: I'm not doing anything with couchdb
16:59 sm oops, bbl
17:03 pointfree I have never looked at the darcsden test suite. I should consider doing so. On a related note, I think a battery of automated performance benchmarks would be in order. Especially with regards to the feed.
17:17 Heffalump FWIW, the existing automtedate dbrowd bd browser based tests are quite hard to maintain
17:27 pointfree Using the CouchDB _changes API may scale much better than my current approach to activity feeds. http://guide.couchdb.org/draft/notifications.html
17:27 gh_ bfrk, ok I would say it's okay to get rid of it
17:27 pointfree sm: Don't compact the CouchDB database!
17:28 pointfree I can retroactively use it as an activity feed.
17:30 pointfree *databases
17:32 gh_ hmm darcs show repo http://darcs.net is currently not an accepted syntax
17:44 sm pointfree: that doesn't sound very robust
17:45 sm by the way, thanks for working on stuff; I'm not responding because I haven't seen much I can help with at the moment
17:56 aristid_ joined #darcs
17:56 pointfree sm: That was my thought at first, but apparently that's the recommended way to do a messaging service or social activity stream with CouchDB.
17:56 pointfree http://docs.couchdb.org/en/2.0.0/api/database/changes.html
17:56 pointfree http://guide.couchdb.org/draft/notifications.html
17:56 pointfree https://pouchdb.com/guides/changes.html
17:56 pointfree Compaction is only useful when you don't need the document history.
17:56 pointfree https://pouchdb.com/guides/compact-and-destroy.html#compacting-a-database
17:56 Gowilla joined #darcs
17:56 kaol_ joined #darcs
18:08 pointfree Thanks, sm, I wasn't sure whether to continue working on darcs stuff or to jump over to pijul. I think PIjul has a lot of potential, but it looks like pijul nest is not open source (hence the licensing change) ...and not only do I see new pijul users, I'm also seeing some new darcs users!
18:09 sm GO DARCS :)
18:10 sm did you get your feeds demo working ?
18:11 pointfree I've got to get another darcs T-shirt. The first one wore out as soon as I started using a top-loader washing machine.
18:12 sm huh, do top loaders wear out clothes quicker ?
18:13 pointfree Yes, much quicker.
18:14 pointfree darcsden builds on my odroid xu4 after deleting ~/.stack
18:24 sm is that a phone ?
18:24 pointfree The feeds demo works...but I just started switching over to a database design based on this http://hub.darcs.net/pointfree/feed-sentences/browse/README.md
18:24 pointfree I should be done with that momentarily. I'll finish that for now -- as a proof of concept. I can stew on the new _changes activity stream approach after that.
18:24 pointfree I think integrating data from multiple databases would be roadblock, and combining the databases into one database may not perform well unless the separate design documents already handle the partitioning.
18:24 pointfree The _changes stream will at least be good for retroactively populating the feed with events such as repo subscriptions.
18:24 pointfree sm: http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825
19:07 bfrk gh_: Ok, thanks. I have another use for the axe I was being handed by sm ;-) namely --repo-name, used by convert and clone. Very similar in nature, i.e. duplicates normal argument and requires extra support in RunCommand. With two extra twists: (1) you can use --repodir as an alias and (2) it is used to to determine where we want the posthook to run. The latter is extremely hacky (we duplicate code from the command to hopefully arrive at the same s
19:08 bfrk %$§%$/%$/ just a few seconds too late
20:06 sm --repodir has been around for ever and is very useful
20:07 sm get/convert's --repo-name seems like a useless alias indeed
20:39 Riastradh joined #darcs
20:43 bfrk sm: --repodir is sacrosanct
20:43 Heffalump bfrk: did you check the tests for --repodir?
20:44 bfrk Heffalump: not yet, my changes are not yet compiling because I mixed it up with something related... happens all the time to me
20:44 Heffalump :-)
20:45 Heffalump I find darcs record is great for sorting that out (I really miss it at work)
20:45 Heffalump did you decide about ? that you were asking about above? I don't have any objection
20:45 Heffalump and you were asking about type signatures a little while ago
20:45 Heffalump plus I still owe you a reply about pijul integration (short answer is mostly negative)
20:46 bfrk Heffalump: I like (?) very much, it has been extremely useful
20:48 bfrk Heffalump: record, yes that is what I am doing now to get things separated; sometimes I also use amend --unrecord (I don't know how I could ever have lived without that!)
20:49 bfrk Heffalump: the pijul question can wait, currently I'm completely in darcs :)
20:53 bfrk One more item for ... well not the axe, perhaps, but the scissors: I want to dim the HINT and NOTE messages a bit, down to a one-liner, in parentheses, and without the shouting ;-)
20:54 Heffalump bfrk: btw you know about editing individual hunks, if you need to tease apart two changes that are too close?
20:54 Heffalump I don't feel strongly about the messages, but it feels a bit bikesheddish to change them now we have them the way they are
20:56 bfrk Heffalump: hunk editing: of course, though I hate it when I have to use it. I was a bit sceptical about the UI at first but now I think it is very well designed and extremely useful
21:00 pointfree sm: The darcsden user feed demo is live: http://odroid.0xffffffff.in:8900/
21:00 pointfree There is no public site-wide feed at the moment, so you'll have to register to try it out.
21:00 pointfree Here's a screenshot of my feed: http://odroid.0xffffffff.in/~deploy/darcsden-feed-screenshots/darcsden-feed.png
21:00 bfrk Heffalump: I can't say why but these messages really annoy me; I have made my peace with the "last regrets". In fact I use them pretty often (when pushing patches but also sometimes when recording or amending) together with the ell key to list what I selected.
21:02 pointfree I will of course be wiping the databases occasionally as I make changes to it, so don't rely on it for anything!
21:02 Riastradh joined #darcs
21:03 pointfree I haven't yet figured out how to access the CouchDB web interface on a headless server.
21:05 bfrk Heffalump: btw, adjacent hunks that don't depend on each other: that is something that pijul offers, right?
21:09 Heffalump bfrk: not sure, haven't tried it
21:10 Heffalump we could support it in darcs too if at least one hunk both adds and removes stuff, but not without a patch format change IIRC
21:11 bfrk And here is yet another BTW: Lately I found hindent to be an extremely useful tool to make sense of very old darcs code. Got a procedure with lines running off the screen edge and formatted like someone ran a buldozer over it? Mark it in the editor, hit the magic button and suddenly you see the structure.
21:12 Heffalump :-)
21:14 bfrk I have even begun to use it for code I write myself, even though my preferred style is not 100%  the same; comes near enough though. It is just extremely convenient.
21:16 bfrk And here is my (hopefully) last one: install lentil (from hackage) and run it with 'src' as argument. Outputs a nicely formatted list of all TODO, FIXME, etc comments. And the list is loooong
21:20 sm nifty
21:25 sm (pointfree, and also bfrk)
21:26 sm bfrk: I support ui cleanups.. maybe mockups showing the proposed before & after will build support
21:27 bfrk sm: how do you do that with a command line tool?
21:28 bfrk sm: ah I understand you refer to the HINTs
21:29 sm yes output changes
21:30 sm last regrets etc.
21:30 sm are you sure you want to convert blah blah
21:30 bfrk sm: yes I will make a proposal with a patch and before/after comparison. good idea. it's not a deep change, so no problem ig it gets voted down
21:30 sm you might have a lot of these and they might not be accepted immediately  - keep em linked somewhere ?
21:31 Heffalump they'll show up on the open patches page
21:31 sm I keep an org file of such things
21:31 Heffalump and I think ben is entitled to just make his own decision if no other darcs reviewer chips in after a while
21:32 bfrk sm: I usually have lots of branches and either they are good and go into screened or they become useless after a while because of too many conflicts.
21:33 sm yeah that sounds heavy for ui tweaks, I'd just be gisting them or something
21:33 sm agreed Heffalump
21:34 bfrk Heffalump: Thanks. I do like to get feedback, pro or con, that's why I ask. You and gh_ often point out things I overlooked
21:35 Heffalump well, we're often busy and we also want to keep the project movin
21:35 Heffalump g
21:38 bfrk btw, I would never dare to do the far-reaching changes that I do now w/o the really great test suite; many kudos to everyone who contributed to that
21:40 sm in another window/world, I am wrestling with travis CI, which is awesome when it works
21:40 sm we could use more stuff like that for darcs
21:40 pointfree We have darcs test/trackdown
21:41 pointfree It could be adapted to serve a similar purpose, perhaps.
21:42 bfrk sm: i don't know travis CI, but I know jenkins and I know we need a buildbot for windows. for another project my Windows co-mainainer uses appveyor
21:42 Riastradh joined #darcs
21:43 sm I'm using appveyor too, it's great
21:43 bfrk sm: can it compile darcs?
21:43 sm stack builds aren't reliable on it (until GHC 8.2), but cabal builds would work
21:44 Heffalump FWIW I've done a bunch of work on darcs test/trackdown but haven't managed to get it in shape for submission yet.
21:44 bfrk sm: you are herewith appointed windows expert for darcs; can you get us on appveyor and -- very importantly -- create binaries/installers?
21:45 sm aieee
21:45 bfrk sm: forgot the ;)
21:45 sm sorry, I can't afford the time, but I'll help anyone
21:46 sm plus, Heffalump is our windows expert
21:46 bfrk sm: oh
21:46 sm but I agree spreading the load is a good idea
21:46 bfrk Heffalump: are you?
21:48 bfrk I am in the forunate position to be able to use darcs at work and I would very much like to get the windows people on board
21:48 bfrk but i haven't used windows in anger for about 15 years...
21:48 sm however, as I think more: how do you hook appveyor or any CI system up to a darcs repo ? or should one mirror to github ?
21:50 bfrk sm: my other project is in darcs too, so it should work
21:51 sm your jenkins project ? I know it can be done locally, I was wondering how to tap into the free CI saas offerings
21:52 sm which provide a lot of value
21:52 bfrk Heffalump: re darcs test, yes I would like to see that. I have not been using it much, yet, but I noticed that it could be a bit easier to set up
21:53 bfrk sm: for jenkins there is a darcs plugin but it is not in good shape, so no: for jenkins we use git mirrors
21:57 bfrk Heffalump: one trivial thing that could be improved: you cannot say 'darcs test ./script', the command must be in the PATH or an absolute  filename
21:58 sm it's a bind.. bringing the best tools to bear on a darcs project requires mirroring to github.. but if you do that folks might just start getting too comfortable with git
21:58 sm hub
21:59 bfrk sm: never. almost all of my coworkers /hate/ git. some prefer mecurial to darcs but git is so unintuitive complex and badly document...
21:59 bfrk ed
22:00 bfrk and even the mercurial fans agree that darcs has its peculiar advantages
22:01 bfrk the only reason git can be used at all is that there are millions of users and there is stackoverflow
22:02 sm those are big reasons.. also I really meant git*hub*, which is another story
22:02 bfrk sm: right (and I should calm down now...)
22:02 pointfree How is Travis CI funded? I'm not sure sm would want a "darcs test" based ci system on darcshub right now :) Before the donate buttons were added I had to figure out that I needed to send the money to sfconservancy which was non-obvious.
22:02 pointfree I can't donate right now because I'm looking for work and my bank account is getting a thinner but I can help with funding some of darcshub once the cash is flowing again. Anyway, I guess Travis CI does premium accounts?
22:03 sm yes they charge for testing private repos
22:03 sm and maybe other things
22:03 bfrk sm: there is not the slightest chance that potential darcs users are unaware of github nowadays
22:05 bfrk joined #darcs
22:22 Riastradh joined #darcs
22:24 bfrk sm: not using github is easy, btw, just put the git repo on a server (e.g. hub.darcs), that should be enough for any CI
22:46 pointfree I looks like the feed fails to update when very large numbers of patches are inserted -- there is a 10k limit on  $DARCS_PATCHES_XML or it could be I need couchdb bulk inserts. This is amounting to a lot of CouchDB documents and it's making me think the darcs patches themselves should be stored in couchdb -- by patch hash so there is not duplication between
22:46 pointfree forks. I think this is what GitHub and others do.
22:47 pointfree I'm beginning to like CouchDB for what its role is. https://nolanlawson.com/2013/11/15/couchdb-doesnt-want-to-be-your-database-it-wants-to-be-your-web-site/
22:53 pointfree The gzipped files themselves could be stored as attachments. The hash_inventory as JSON. I'd need to think more about how this would work through ssh-server.
23:11 dolio joined #darcs

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary