beancount.ingest is no more. Long live beangulp!

[Martin Blais]

Hi,

Part of v3 plans is thinning out the repository.

I've just moved the beancount.ingest directory from beancount to a new repository.

Announcing:

https://github.com/beancount/beangulp

In keeping with all things of the bean (beanthings?), this one becomes "beangulp".

I hope you like the name, it gives me childish giggles everytime I think about it.

I have no idea why, just the sound of it.

- If you were using beancount/master (v3), you should be able to fixup your imports and add to your PYTHONPATH (there is no setup yet).

However, expect some things to change (nothing too radical, mostly simplifications):

https://docs.google.com/document/d/1O42HgYQBQEna6YpobTqszSgTGnbRX7RdjmzR2xumfjs/edit#

- However, the bean-file, bean-extract, bean-identify tools are gone (thanks Daniele!).

The new code will require that the configuration becomes a Python script.

- Nothing changed in v2, everything is still there.

If you want things stable, stick with v2.

Look forward to a renewed, simpler and leaner importer framework,

[Martin Michlmayr]

* Martin Blais <bl...@furius.ca> [2021-02-02 01:20]:

> - Nothing changed in v2, everything is still there.
> If you want things stable, stick with v2.

Since beangulp creates transactions on stdout, is it possible to
migrate from ingest to beangulp while staying on v2 for other
functionality? (or is that not possible because beancount v2
and v3 can't be installed at the same time?)

--
Martin Michlmayr
https://www.cyrius.com/

[Daniele Nicolodi]

On 02/02/2021 07:28, Martin Michlmayr wrote:
> * Martin Blais <bl...@furius.ca> [2021-02-02 01:20]:
>> - Nothing changed in v2, everything is still there.
>> If you want things stable, stick with v2.
>
> Since beangulp creates transactions on stdout, is it possible to
> migrate from ingest to beangulp while staying on v2 for other
> functionality? (or is that not possible because beancount v2
> and v3 can't be installed at the same time?)
>

As there has been yet no incompatible ledger format change, you can have
two virtual environments: one with Beancount v2 and one with Beancount
v3. However, at this point, there is no reason to stick to v2 if you
want to experiment, as the major changes implemented there are not active.

Cheers,
Dan

[Martin Blais]

I have both and switch and git checkout and rebuild back and forth. Requires PYTHONPATH and local repos, not installed

Beangulp will be sync'ed to master/v3 and if something it depends on changes in beancount and you're running it on top of a v2 install it might break so at some point compatibility may break. 

Beangulp/beangrow/beanlabs and other repos are all assumed to work only with v3 like that. It's the new world. Beanprice is an exception: it's only  dependent on beancount at the edges (for output syntax, for optional extracting lists of currencies from the ledger, it barely needs a few imports, and will be decoupled, beancount dependencies isolated, i.e. a hledger user without a beancount install should be able to use it) and Kirill wants support for both v2 and v3.

Why not find a way to have two setups?

You could run your v2 installed with virtualenv, and your v3 setup like me from clones. That should work. FWIW, right now v3 still runs fine without the new compilation, the new c++ code is incomplete and not hooked up yet, it's living on the side in the ccore and cparser directories on branch master. At some point it'll switch over and it'll require a big fat bazel build to do anything at all but we're not close to that yet. Also, there will be a switchover to a public API as well at some point (all code outside the beancount repo will use a single import just like numpy, and that probably will break any circumstancial compatibility with v2 for projects that migrate to that api).

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20210202062819.GE2765%40jirafa.cyrius.com.

[kuba....@gmail.com]

Regarding importer development on v2, if I was to make changes to csv.py, will the changes be migrated from the v2 branch into beangulp?

I'm still unsure of how to use beangulp and I would like to make changes to the importers so will I need to port the changes over myself once I familiarise myself with the new world?

Kind regards,

Kuba

[Martin Blais]

On Thu, Feb 11, 2021 at 4:53 PM kuba....@gmail.com <kuba....@gmail.com> wrote:

Regarding importer development on v2, if I was to make changes to csv.py, will the changes be migrated from the v2 branch into beangulp?

I don't think a whole lot of development will happen on v2 anymore, especially for ingest and beanprice which have migrated out.

Consider v2 frozen.

I would suggest to please send a CL to beangulp for that.

 

 

I'm still unsure of how to use beangulp and I would like to make changes to the importers so will I need to port the changes over myself once I familiarise myself with the new world?

It'll be really quite similar, we're not adding a whole lot of new features, but rather making things simpler that should have been simple in the first place, learning from the lessons of having had to build a bunch of importers and working with them. We'll update the examples in the beangulp repo, don't worry. 99% of your code will be directly usable (all the hard parts anyway).

Did I share the doc?  Here are the changes:

https://docs.google.com/document/d/1O42HgYQBQEna6YpobTqszSgTGnbRX7RdjmzR2xumfjs/edit

dnicolodi@'s been doing great work and developing these changes and I'm looking forward to try it out and convert all my importers.

If you have any ideas for how to make it better, please add them to the doc,

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/52473f54-1870-4906-a639-45ddcdb5add3n%40googlegroups.com.

[Daniele Nicolodi]

On 11/02/2021 22:53, kuba....@gmail.com wrote:
> Regarding importer development on v2, if I was to make changes to
> csv.py, will the changes be migrated from the v2 branch into beangulp?
>
> I'm still unsure of how to use beangulp and I would like to make changes
> to the importers so will I need to port the changes over myself once I
> familiarise myself with the new world?

Hello Kuba,

currently the v2 codebase is in maintenance mode: only bug fixes and
changes that can be trivially merged into v3 are likely to be accepted.
This disqualifies most changes to the ingestion framework that are not
fixes for bugs affecting users.

Also, if anything, I expect the CSV importer in beangulp to become
simpler, and not to gain new features. It was intended as an example to
demonstrate how to write an importer and grow into something with a know
for every aspect, and it deviated from its original scope.

However, if you have some improvements in mind, we can discuss them case
by case. Please feel free to send PRs for beangulp.

So far, the only thing that changed in bengulp is the command line
interface, thus all existing importers can be easily migrated to it by
simply fixing the imports.

Installing beangulp should be easy:

$ python -m venv gulp
$ cd gulp
$ ./bin/pip install git+https://github.com/beancount/beancount/
$ ./bin/pip install git+https://github.com/beancount/beangulp/

or

$ git checkout https://github.com/beancount/beangulp/
$ cd beangulp
$ python -m venv .
$ ./bin/pip install git+https://github.com/beancount/beancount/
$ ./bin/python setup.py develop

if you want to hack on the code, or similar incantations.

Cheers,
Dan

[kuba....@gmail.com]

Thank you both, 

Martin for the beangulp documentation and Dan for the clear instructions.

As a result I've managed to convert one of my scripts quite easily.

However on running the extract command, I am immediately hit with an issue with the rounding of the amount.

What used to be in v2

2020-12-29 * "INTEREST PAID AFTER TAX 0.00 DEDUCTED, 7.69"

  Assets:Current:S  7.69 GBP

is now 

2020-12-29 * "INTEREST PAID AFTER TAX 0.00 DEDUCTED, 7.69"

  Assets:Current:S  7.69000000000000039079850466805510222911834716796875 GBP

I think beangulp is quite neat but I have some concerns around its day to day use but perhaps that is because I have not been using it properly yet.

I have all my importers in their own git repos, most of which are not production ready and so are not on pypi. I guess in fact most peoples importers may be so specific to their needs that they would not be put on pypi either.

So in world where we all have multiple importers in development, would the recommendation be a) to install the importers into the venv of beangulp or b) to create a venv for each importer and install beangulp into each or c) some other option?

a) Is easier to use because one would not need to switch venvs while importing.

b) Protects against package issues between importers.

c) Perhaps it's enough to add my importers to the PYTHON_PATH and hope for the best.

Kind regards,

Kuba.

[Martin Blais]

On Thu, Feb 11, 2021 at 6:23 PM kuba....@gmail.com <kuba....@gmail.com> wrote:

Thank you both, 

Martin for the beangulp documentation and Dan for the clear instructions.

As a result I've managed to convert one of my scripts quite easily.

However on running the extract command, I am immediately hit with an issue with the rounding of the amount.

What used to be in v2

2020-12-29 * "INTEREST PAID AFTER TAX 0.00 DEDUCTED, 7.69"

  Assets:Current:S  7.69 GBP

is now 

2020-12-29 * "INTEREST PAID AFTER TAX 0.00 DEDUCTED, 7.69"

  Assets:Current:S  7.69000000000000039079850466805510222911834716796875 GBP

This is likely related to the fact that the display context from your ledger file isn't loaded.

(In v3 I'm completely reviewing all the tolerances and precision and how this is done.)

I think beangulp is quite neat but I have some concerns around its day to day use but perhaps that is because I have not been using it properly yet.

To be clear, beangulp isn't really a new thing. It's literally the beancount.ingest code I've copied over so we can make it better and evolve it a bit faster.

I have all my importers in their own git repos, most of which are not production ready and so are not on pypi. I guess in fact most peoples importers may be so specific to their needs that they would not be put on pypi either.

So in world where we all have multiple importers in development, would the recommendation be a) to install the importers into the venv of beangulp or b) to create a venv for each importer and install beangulp into each or c) some other option?

a) Is easier to use because one would not need to switch venvs while importing.

b) Protects against package issues between importers.

c) Perhaps it's enough to add my importers to the PYTHON_PATH and hope for the best.

I don't know.

We have stable: v2 (beancount v2 + beancount.ingest) and development: beancount/master + beangulp.

Choose one. 

If things occasionally breaking due to changes bothers you, stick with v2.

If you want the goodness of new things, and are willing to make changes when necessary, use the master branch and development repos.

 

--

You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/b8f0474c-ee18-46b9-8952-ff56b9e08ddcn%40googlegroups.com.

[kuba....@gmail.com]

Hi all, 

On Friday, 12 February 2021 at 02:20:11 UTC+1 bl...@furius.ca wrote:

On Thu, Feb 11, 2021 at 6:23 PM kuba....@gmail.com <kuba....@gmail.com> wrote:

Thank you both, 

Martin for the beangulp documentation and Dan for the clear instructions.

As a result I've managed to convert one of my scripts quite easily.

However on running the extract command, I am immediately hit with an issue with the rounding of the amount.

What used to be in v2

2020-12-29 * "INTEREST PAID AFTER TAX 0.00 DEDUCTED, 7.69"

  Assets:Current:S  7.69 GBP

is now 

2020-12-29 * "INTEREST PAID AFTER TAX 0.00 DEDUCTED, 7.69"

  Assets:Current:S  7.69000000000000039079850466805510222911834716796875 GBP

This is likely related to the fact that the display context from your ledger file isn't loaded.

(In v3 I'm completely reviewing all the tolerances and precision and how this is done.)

So I have had a success although I don't understand why. 

Last night I ended up converting my old import config with all my importers in it into beangulp and since then the display context issue is not visible. 

It's strange that it now works given my importers are the same but perhaps the problem depends on the order of loading of importers or the fact that my test script only had one importer?

 

I think beangulp is quite neat but I have some concerns around its day to day use but perhaps that is because I have not been using it properly yet.

To be clear, beangulp isn't really a new thing. It's literally the beancount.ingest code I've copied over so we can make it better and evolve it a bit faster.

I have all my importers in their own git repos, most of which are not production ready and so are not on pypi. I guess in fact most peoples importers may be so specific to their needs that they would not be put on pypi either.

So in world where we all have multiple importers in development, would the recommendation be a) to install the importers into the venv of beangulp or b) to create a venv for each importer and install beangulp into each or c) some other option?

a) Is easier to use because one would not need to switch venvs while importing.

b) Protects against package issues between importers.

c) Perhaps it's enough to add my importers to the PYTHON_PATH and hope for the best.

I don't know.

We have stable: v2 (beancount v2 + beancount.ingest) and development: beancount/master + beangulp.

Choose one. 

If things occasionally breaking due to changes bothers you, stick with v2.

If you want the goodness of new things, and are willing to make changes when necessary, use the master branch and development repos.

After converting my old import config i'm finding the process easy enough. My workflow is entirely in Vim so I've had to learn how to use a virtual environment from inside Vim but that was easy enough.

Moving forward as I would like to make changes to the CSV importer so I will use beangulp for importing and beancount v3 as much as possible, but if something breaks, presumably I can continue using beangulp for importing and v2 for the rest?

Kind regards,

Jakub Jamro.

[Martin Blais]

On Fri, Feb 12, 2021 at 11:55 AM kuba....@gmail.com <kuba....@gmail.com> wrote:

Hi all, 

On Friday, 12 February 2021 at 02:20:11 UTC+1 bl...@furius.ca wrote:

On Thu, Feb 11, 2021 at 6:23 PM kuba....@gmail.com <kuba....@gmail.com> wrote:

Thank you both, 

Martin for the beangulp documentation and Dan for the clear instructions.

As a result I've managed to convert one of my scripts quite easily.

However on running the extract command, I am immediately hit with an issue with the rounding of the amount.

What used to be in v2

2020-12-29 * "INTEREST PAID AFTER TAX 0.00 DEDUCTED, 7.69"

  Assets:Current:S  7.69 GBP

is now 

2020-12-29 * "INTEREST PAID AFTER TAX 0.00 DEDUCTED, 7.69"

  Assets:Current:S  7.69000000000000039079850466805510222911834716796875 GBP

This is likely related to the fact that the display context from your ledger file isn't loaded.

(In v3 I'm completely reviewing all the tolerances and precision and how this is done.)

So I have had a success although I don't understand why.  

Last night I ended up converting my old import config with all my importers in it into beangulp and since then the display context issue is not visible. 

Could it that somehow the ledger file was silently ignored, due to a bug in us ignoring it and you making a typo in the filename?

That would be a classic.

 

 

It's strange that it now works given my importers are the same but perhaps the problem depends on the order of loading of importers or the fact that my test script only had one importer?

I'm not sure; if you are able to reproduce it and isolate it that would be helpful.

I think beangulp is quite neat but I have some concerns around its day to day use but perhaps that is because I have not been using it properly yet.

To be clear, beangulp isn't really a new thing. It's literally the beancount.ingest code I've copied over so we can make it better and evolve it a bit faster.

I have all my importers in their own git repos, most of which are not production ready and so are not on pypi. I guess in fact most peoples importers may be so specific to their needs that they would not be put on pypi either.

So in world where we all have multiple importers in development, would the recommendation be a) to install the importers into the venv of beangulp or b) to create a venv for each importer and install beangulp into each or c) some other option?

a) Is easier to use because one would not need to switch venvs while importing.

b) Protects against package issues between importers.

c) Perhaps it's enough to add my importers to the PYTHON_PATH and hope for the best.

I don't know.

We have stable: v2 (beancount v2 + beancount.ingest) and development: beancount/master + beangulp.

Choose one. 

If things occasionally breaking due to changes bothers you, stick with v2.

If you want the goodness of new things, and are willing to make changes when necessary, use the master branch and development repos.

After converting my old import config i'm finding the process easy enough. My workflow is entirely in Vim so I've had to learn how to use a virtual environment from inside Vim but that was easy enough.

Moving forward as I would like to make changes to the CSV importer so I will use beangulp for importing and beancount v3 as much as possible, but if something breaks, presumably I can continue using beangulp for importing and v2 for the rest?

Yes, you should be.

As I said, you can set a venv to run v2 and run v3 from HEAD, should be fine.

Just create two importer scripts.

I'll respond to the CSV question on the other thread

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/198987ad-03c8-48bc-b848-2ce253e680c5n%40googlegroups.com.

[Daniele Nicolodi]

On 02/02/2021 07:28, Martin Michlmayr wrote:

> * Martin Blais <bl...@furius.ca> [2021-02-02 01:20]:
>> - Nothing changed in v2, everything is still there.
>> If you want things stable, stick with v2.
>
> Since beangulp creates transactions on stdout, is it possible to
> migrate from ingest to beangulp while staying on v2 for other
> functionality? (or is that not possible because beancount v2
> and v3 can't be installed at the same time?)

Thinking about it, there is no reason for beangulp to require beancount
v3, thus I could easily lower the minimum required beancount version for
banngulp, if it makes life easier for someone.

The main rationale for beangulp requiring beancount 3.0.dev0 is that in
this version the old ingest framework is gone and thus it is easier to
spot the imports that needs to be updated to the new location in the
code using them, and it makes it impossible to mix imports from
different locations, with possibly nasty bugs hard to diagnose.

Cheers,
Dan

[kuba....@gmail.com]

Let say that for my case that certainly wouldn't be needed. The upgrade to v3 was pretty painless and at the moment everything works.

If a time came where development broken something on v3, I would probably stick to an older revision of v3 rather then jump back to v2.

 

Cheers,
Dan

[Daniele Nicolodi]

On 02/02/2021 07:20, Martin Blais wrote:
> Hi,
>
> Part of v3 plans is thinning out the repository.
> I've just moved the beancount.ingest directory from beancount to a new
> repository.
> Announcing:
> https://github.com/beancount/beangulp

When beangulp was split off from the beancount repository, the git
history was not preserved. Among other things, this made it not easy to
identify contributors to the code. To address this, I used
git-filter-repo to carve beangulp out of beancount preserving history. I
just foce pushed the result to the beangulp master branch.

The contents of the repository are identical, but the most recent git
commits have been rebased and thus have different commit IDs. If anyone
has open pull request or local commits, these will need to be rebased on
top of the new repository head. "git rebase --help" has instructions on
how to do it in the "RECOVERING FROM UPSTREAM REBASE" section. Let me
know if you need help with it.

I think I started this work when most likely I was the only one beangulp
changes pending merge (Github reported that there were only an handful
of forks of the beangulp repo and none had any commit to it).
Unfortunately, by the time I pushed the new history a PR for beangulp
popped up. I hope it is not too much trouble to rebase it.

Sorry for the disruption, but I feel that preserving the history was
worth the inconvenience.

Cheers,
Dan

[Ben Blount]

No problem Daniele, thanks for fixing up the history!

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/7ee5273f-9857-6d83-9f0a-f667ac34c16d%40grinta.net.

[Martin Blais]

Thank you for doing this!

[kuba....@gmail.com]

Hi all,

I have a question about beangulp. I've noticed that compared to beancount.ingest, beangulp now produces more logging when doing an extract so I wanted to question why it's there.

In my specific case, I use beangulp directly within vim to import transactions directly into my beancount file.

Using beancount.ingest the resulting text required no alteration as it only contained the header containing the filename and the transactions.

But using beangulp, now I have to clean up the text because it has some logging to indicate the progress of the overall extraction which results in something like below (highlighted yellow).

(gulp) [picasso@xps-13 beancount.dm-crypt]$ python gulp.py extract downloads/account-2021-04.ofx 

* /run/media/picasso/beancount.dm-crypt/downloads/account-2021-04.ofx ... OK

;; -*- mode: beancount -*-

**** /run/media/picasso/beancount.dm-crypt/downloads/flexaccount-2021-04.ofx

2021-04-01 * "Transfer"

  Assets:Account  20.0 GBP

I see that the information logging is output on stderr so I can redirect it to /dev/null however I would like to know how everyone else is using beangulp and whether this change of behaviour is only affecting me or other too.

Actually even the beancount mode header also is superfluous in almost all of my cases but that is also being produced beancount.ingest.

[Daniele Nicolodi]

On 06/09/2021 18:11, kuba....@gmail.com wrote:
> Hi all,
>
> I have a question about beangulp. I've noticed that compared to
> beancount.ingest, beangulp now produces more logging when doing an
> extract so I wanted to question why it's there.

> I see that the information logging is output on stderr so I can redirect
> it to /dev/null however I would like to know how everyone else is using
> beangulp and whether this change of behaviour is only affecting me or
> other too.

You answered your own question.

The tool is supposed to be used redirecting only the standard output to
a ledger while the standard error is used for status messages. This is
standard practice in Unix tools.

Also, when the extract command encounters an exception raised by one of
the importers, it dumps it on standard error, continues execution, but
exists with an error. If you are looking into integrating beangulp into
your pipeline, most probably you want to handle this explicitly.

> Actually even the beancount mode header also is superfluous in almost
> all of my cases but that is also being produced beancount.ingest.

You can customize the header assigning to beangulp.extract.HEADER

Cheers,
Dan

[Daniele Nicolodi]

On 06/09/2021 20:53, Daniele Nicolodi wrote:
> On 06/09/2021 18:11, kuba....@gmail.com wrote:
>> Hi all,
>>
>> I have a question about beangulp. I've noticed that compared to
>> beancount.ingest, beangulp now produces more logging when doing an
>> extract so I wanted to question why it's there.
>
>> I see that the information logging is output on stderr so I can redirect
>> it to /dev/null however I would like to know how everyone else is using
>> beangulp and whether this change of behaviour is only affecting me or
>> other too.
>
> You answered your own question.
>
> The tool is supposed to be used redirecting only the standard output to
> a ledger while the standard error is used for status messages. This is
> standard practice in Unix tools.

I forgot to mention: there is also the documented '--quiet' option to
suppress all diagnostic output, if that is what you prefer.

Cheers,
Dan

[kuba jamro]

Thanks for that.

Now that I think about it I think I will create a wrapper for myself to have the --quiet option on by default. 

Kind regards,

Jakub. 

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/YhBQEh7xVdk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/b0a82aaf-9a88-6b59-c444-a7d9571a3411%40grinta.net.

[Daniele Nicolodi]

On 07/09/2021 13:50, kuba jamro wrote:
> Thanks for that.
>
> Now that I think about it I think I will create a wrapper for myself to
> have the --quiet option on by default. 

That does not make much sense [1], but you're free too pick your poison.

[1] You have a process that does the equivalent of

import.py extract documents/ >ledger.beancount 2>&1

and you complain that standad error ends up in ledger.beancount. Your
solution is to use a wrapper that does:

#!/bin/sh

command=$1
shift

case $1 in
extract)
import.py $command -q $*
;;
*)
import.py $command $*
;;
esac

thus suppressing output to standard error from import.py estract.

I argue that this is way more complex than required and, as already
pointed out, it writes to the ledger the error messages reported by the
importers and silently ignores them.

Wouldn't it be much simpler to drop the redirection of standard error to
standard output (aka 2>&1) from the invocation of import.py or, as I
understand your use case, to instruct Vim to do not capture the standard
error of the process it invokes?

Cheers,
Dan

[Red S]

It'd be helpful to release beangulp on PyPI. I'm wondering if there are plans to do so? Thanks.

[Red S]

Also, there are references to v3 and v2 in README.md, which are now presumably out of date, given beangulp works fine on v2 as well? Should these be updated?

[Martin Blais]

No plans.

On Tue, Oct 18, 2022 at 4:20 AM Red S <redst...@gmail.com> wrote:

It'd be helpful to release beangulp on PyPI. I'm wondering if there are plans to do so? Thanks.

--

You received this message because you are subscribed to the Google Groups "Beancount" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/d12ddfef-3ee1-486c-8b16-ac064942a2b0n%40googlegroups.com.

[Martin Blais]

Done. Thanks for reminding.

On Tue, Oct 18, 2022 at 5:32 AM Red S <redst...@gmail.com> wrote:

Also, there are references to v3 and v2 in README.md, which are now presumably out of date, given beangulp works fine on v2 as well? Should these be updated?

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/379eda71-b8c1-44c7-90c3-65f1c749c7e2n%40googlegroups.com.