Re: [Python-Dev] Tools/unicode
On 03/01/2011 16:19, M.-A. Lemburg wrote: Michael Foord wrote: On 03/01/2011 15:39, Alexander Belopolsky wrote: On Mon, Jan 3, 2011 at 10:33 AM, Michael Foord wrote: .. If someone knows if this tool is still used/useful then please let us know how the description should best be updated. If there are no replies I'll remove it. If you are talking about Tools/unicode/, this is definitely a very useful tool used to generate unicodedata and encoding modules from raw unicode.org files. The description currently reads "Tools used to generate unicode database files". I'll update it to read: "tool used to generate unicodedata and encoding modules from raw unicode.org files" Make that "Tools for generating unicodedata and codecs from unicode.org and other mapping files". The scripts in that dir are not just one tool, but several tools needed to maintain the Unicode database in Python as well as generate new codecs from mapping files. Thanks Marc-Andre. I'll add you and Martin as maintainers in the README description as well. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools/unicode
Michael Foord wrote: > On 03/01/2011 15:39, Alexander Belopolsky wrote: >> On Mon, Jan 3, 2011 at 10:33 AM, Michael >> Foord wrote: >> .. >>> If someone knows if this tool is still used/useful then please let us >>> know >>> how the description should best be updated. If there are no replies I'll >>> remove it. >> If you are talking about Tools/unicode/, this is definitely a very >> useful tool used to generate unicodedata and encoding modules from raw >> unicode.org files. > The description currently reads "Tools used to generate unicode database > files". I'll update it to read: > > "tool used to generate unicodedata and encoding modules from raw > unicode.org files" Make that "Tools for generating unicodedata and codecs from unicode.org and other mapping files". The scripts in that dir are not just one tool, but several tools needed to maintain the Unicode database in Python as well as generate new codecs from mapping files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 03 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools/unicode
On 03/01/2011 15:39, Alexander Belopolsky wrote: On Mon, Jan 3, 2011 at 10:33 AM, Michael Foord wrote: .. If someone knows if this tool is still used/useful then please let us know how the description should best be updated. If there are no replies I'll remove it. If you are talking about Tools/unicode/, this is definitely a very useful tool used to generate unicodedata and encoding modules from raw unicode.org files. The description currently reads "Tools used to generate unicode database files". I'll update it to read: "tool used to generate unicodedata and encoding modules from raw unicode.org files" All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools/unicode
On Mon, Jan 3, 2011 at 10:33 AM, Michael Foord wrote: .. > If someone knows if this tool is still used/useful then please let us know > how the description should best be updated. If there are no replies I'll > remove it. If you are talking about Tools/unicode/, this is definitely a very useful tool used to generate unicodedata and encoding modules from raw unicode.org files. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tools/unicode
Hello all, In the Tools/ directory (py3k) we have a tool/directory called "unicode". The description in Tools/README is: unicode Tools used to generate unicode database files for Python 2.0 (by Fredrik Lundh). As described this is not at all useful for Python 3.2. I'm removing the "for Python 2.0" from the description, but I would rather remove the tool altogether. If someone knows if this tool is still used/useful then please let us know how the description should best be updated. If there are no replies I'll remove it. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 5, 2009, at 7:37 PM, Matthias Klose wrote: Barry Warsaw schrieb: Someone (I'm sorry, I forgot who) asked me at Pycon about stripping out Demos and Tools. I'm happy to remove the two I wrote - Tools/world and Tools/pynche - from the distribution and release them as separate projects (retaining the PSF license). Should I remove them from both the Python 2.x and 3.x trunks? +1, but please for 2.7 and 3.1 only. Yes, of course. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdoE0XEjvBPtnXfVAQIyFgP+MqBghtSqVigJF9w/u47npaheOusITPWT iUeeJfTFDDHBKyYKXOwpASW+SahtnTO3OTR3f40S0Ptf+HRGo0J2efWUWcbXkN5X ikrHePT8YIp0MC4qYcUAfNrSNtgYxJuVKd7ARCFotBSN3Nu+bxzPO+LGw5xhlvbT Q3H3f3TQM3A= =nCUB -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools
On Sun, Apr 5, 2009 at 10:58 PM, Jack diederich wrote: > On Sun, Apr 5, 2009 at 10:50 PM, wrote: >> Barry> Someone asked me at Pycon about stripping out Demos and Tools. >> >> Matthias> +1, but please for 2.7 and 3.1 only. >> >> Is there a list of other demos or tools which should be deleted? If >> possible the list should be publicized so that people can pick up external >> maintenance if desired. > > I liked Brett's (Georg's?) half joking idea at sprints. Just delete > each subdirectory in a separate commit and then wait to see what > people revert. > > -Jack Jack brought up a good point - this discussion came up during the sprints, I believe Martin and others had some good arguments to keep *some* of the demo/... stuff, however I think we all agreed that it belongs somewhere else; possibly the documentation. As it is, the demo/... directory only exists in subversion - it's not installed anywhere. I really do think that most of the contents can either be deleted, or moved to the docs where it might be of more use for people in general. Random thought - what if we made a docs/demos directory, which contained sub directories ala Demo/... - and added a sphinx extension which would detect nested directories and zip them up during the build? This way, you could add a tag in the .rst for the module that looked like: .. demos:: multiprocessing.zip The zip would not be checked in, but created at build time from Docs/demos/multiprocessing Just some thoughts. Back to my coffee. -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools
On Sun, Apr 5, 2009 at 10:50 PM, wrote: > Barry> Someone asked me at Pycon about stripping out Demos and Tools. > > Matthias> +1, but please for 2.7 and 3.1 only. > > Is there a list of other demos or tools which should be deleted? If > possible the list should be publicized so that people can pick up external > maintenance if desired. I liked Brett's (Georg's?) half joking idea at sprints. Just delete each subdirectory in a separate commit and then wait to see what people revert. -Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools
Barry> Someone asked me at Pycon about stripping out Demos and Tools. Matthias> +1, but please for 2.7 and 3.1 only. Is there a list of other demos or tools which should be deleted? If possible the list should be publicized so that people can pick up external maintenance if desired. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools
Barry Warsaw schrieb: > Someone (I'm sorry, I forgot who) asked me at Pycon about stripping out > Demos and Tools. I'm happy to remove the two I wrote - Tools/world and > Tools/pynche - from the distribution and release them as separate > projects (retaining the PSF license). Should I remove them from both > the Python 2.x and 3.x trunks? +1, but please for 2.7 and 3.1 only. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools
2009/4/5 Barry Warsaw : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Someone (I'm sorry, I forgot who) asked me at Pycon about stripping out > Demos and Tools. I'm happy to remove the two I wrote - Tools/world and > Tools/pynche - from the distribution and release them as separate projects > (retaining the PSF license). Should I remove them from both the Python 2.x > and 3.x trunks? +1 to removing some of the old unused stuff from those directories. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Someone (I'm sorry, I forgot who) asked me at Pycon about stripping out Demos and Tools. I'm happy to remove the two I wrote - Tools/ world and Tools/pynche - from the distribution and release them as separate projects (retaining the PSF license). Should I remove them from both the Python 2.x and 3.x trunks? Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdj2S3EjvBPtnXfVAQJvkAQAhj/Go+OtfYP//OZ7HIHwTjaeMlpAkfwn iPxE6O8gY0K48J1AUmjvGSeckfP4FRqVJWOVMQYvX8yTHNFnCJxDSl4JjgboqLz4 s/IvrUYjSiN1FGrQJBA3RI4jFmuetzmKxNWgi6gEzQ6ocTLC80EyCHhxsAMhCeqr SGQ+Alrewis= =ODWt -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause
Committed new version of kill_python to trunk in r62129. Trent. From: "Martin v. Löwis" [EMAIL PROTECTED] Sent: 02 April 2008 14:39 To: Trent Nelson Cc: python-dev@python.org Subject: Re: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause > That'll kill the first python_d.exe instance it finds matching the > given path; given that our buildbots run trunk/release25-maint/py3k > in parallel That's actually not a given: we currently *don't* run multiple builds simultaneously on the same slave. > Unless anyone advises otherwise, I'll start on a patch. If you can make it less error-prone, sure, go ahead. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause
Trent Nelson wrote: >>> That'll kill the first python_d.exe instance it finds matching the >>> given path; given that our buildbots run trunk/release25-maint/py3k >>> in parallel >> That's actually not a given: we currently *don't* run multiple builds >> simultaneously on the same slave. > > I thought the slave lock only applied per branch, not per host? As the name suggests, it's per slave :-) a slave being the name/password pair, along with the buildbot.tac file. The sequencing of builds per builder is not a locking mechanism, actually; a single builder just won't schedule a new build as long as a build is already running. So we have currently three builders per slave, and these are serialized with the slave lock (hence the occasional long sequences of yellow "Build nnn": the build starts, tries to acquire the slave lock, which then a different builder still holds). Now, on your machine, I understand you also have two slaves running. They might, in principle, kill each other's python_d.exe processes, except that the paths will be different there (amd64 vs. not). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause
> > That'll kill the first python_d.exe instance it finds matching the > > given path; given that our buildbots run trunk/release25-maint/py3k > > in parallel > > That's actually not a given: we currently *don't* run multiple builds > simultaneously on the same slave. I thought the slave lock only applied per branch, not per host? > > Unless anyone advises otherwise, I'll start on a patch. > > If you can make it less error-prone, sure, go ahead. Spent a bit of time on it this evening; as it happens, in order to enumerate 64-bit processes, you need to be a 64-bit process yourself. As it's much easier managing 32-bit vs. x64 binaries when they're a .vcproj part of pcbuild.sln, I'm looking into adding kill_python as a .vcproj and configure the solution such that it builds and runs this before any other project. That'll automatically take care of choosing the right version to run depending on whether 'Win32' or 'x64' is selected as the platform. It'll also simplify the verification logic that checks if it's the right python_d.exe -- the path of the .exe needs to match the path of the running kill_python.exe. Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause
> That'll kill the first python_d.exe instance it finds matching the > given path; given that our buildbots run trunk/release25-maint/py3k > in parallel That's actually not a given: we currently *don't* run multiple builds simultaneously on the same slave. > Unless anyone advises otherwise, I'll start on a patch. If you can make it less error-prone, sure, go ahead. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause
Looking into some of the recent Windows buildbot failures, I see things like
this:
sqlite3 : error PRJ0008 : Could not delete file
'c:\buildbot\trunk.heller-windows-amd64\build\PCbuild\amd64\sqlite3_d.dll'.
build-amd64.bat doesn't go through the kill_python.c hoopla, so I figure the
above error is being caused by the fact that an erroneous/stalled python_d.exe
from a previous run is still open. I was looking at modifying kill_python.c to
accept an 'x64' argument if we want to kill amd64\python_d.exe instead of the
usual 32-bit exe, however, this caught my attention:
if ((strstr(path, "pcbuild\\python_d.exe") != NULL) ||
(strstr(path, "\\build\\python.exe") != NULL)) {
printf("Terminating %s (pid %d)\n", path, pids[i]);
if (!TerminateProcess(hProcess, 1)) {
printf("Termination failed: %d\n", GetLastError());
return 1;
}
return 0;
That'll kill the first python_d.exe instance it finds matching the given path;
given that our buildbots run trunk/release25-maint/py3k in parallel, it seems
as though it wouldn't be hard for us to get into a situation where
kill_python.exe ends up killing the wrong python_d.exe (i.e. trunk checkin,
trunk builds, starts testing, py3k checkin, calls kill_python.exe, kills
trunk's python_d.exe that was in the middle of testing).
That can't be helping our cause, unless I'm missing something... Unless anyone
advises otherwise, I'll start on a patch.
Trent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
Brett Cannon wrote: > On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote: >> [finding Tools/i18n/pygettext.py] >> > You're right, I think Tools is probably a bad place for >> > anything. If it's not part of the stdlib, I'll likely never >> > find it. >> >> Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ >> scripts could be put in __main__ sections of appropriate modules? So that >> "python -m gettext" would be equivilant to "python Tools/i18n/pygettext.py"? Questionable. Most scripts don't correspond to a single library module. >> (However, pyggettext.py is 22KB, which is a big addition to the module; not >> everything in Tools/Scripts might be used enough for this, or have an >> appopriate module to be put in either). >> >> Are there other ideas about how Tools/ could be improved? Either moving >> things, or making it more likely that people will look there for scripts? >> > > I assume that the Windows installer includes the Tools/ directory. If > it doesn't that is one problem. =) > > Otherwise it is mostly a lack of advertisement and them not being > installed by ``make install``. If you just download the soure and > install you will never know the directory even exists. It needs to be > made obvious to people that it is even there. +1. Most non-Windows users with distribution-supplied Pythons will never get the Tools directory on their installs though there is a number of really useful scripts there. Question is, if ``make install`` should install it, where? Has the time come for /usr/share/python? Or /usr/lib/pythonX.Y/Tools (without __init__.py)? > Probably the only way is to document the directory. I think so, too. The tools are worth a top-level documentation entry. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
Jim Jewett wrote: >>How should we document [the tools directory] > > > At the interactive prompt, help() lets me get a list > of topics (not including tools), keywords, or modules -- > but no mention of tools. > > I didn't find any references at http://python.org/doc/ > > The tutorial does mention the standard library (and > the library reference documents it), but I didn't find > any suggestion in either that there was another > library out there under a Tools or Scripts directory. Even adding something (e.g., Tools/README) to the "undocumented modules" section of the standard library would be an improvement on the status quo. I also noticed that the Windows installer does *not* install "Tools/README.txt", so there isn't even a synopsis of the tools which _are_ included with the Windows installer. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
> How should we document [the tools directory] At the interactive prompt, help() lets me get a list of topics (not including tools), keywords, or modules -- but no mention of tools. I didn't find any references at http://python.org/doc/ The tutorial does mention the standard library (and the library reference documents it), but I didn't find any suggestion in either that there was another library out there under a Tools or Scripts directory. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
[Brett Cannon] > I assume that the Windows installer includes the Tools/ directory. It installs part of it, not all: C:\Python24\Tools>dir/b i18n pynche Scripts versioncheck webchecker So it's missing these Tools directories: audiopy bgen compiler faqwiz framer freeze modulator msi unicode world Historically, a Tools directory got into the Windows installer iff somone asked for it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
On Thu, Sep 08, 2005 at 06:52:59PM -0700, Brett Cannon wrote: > Otherwise it is mostly a lack of advertisement and them not being > installed by ``make install``. If you just download the soure and Agreed. I've often wished that reindent.py was installed somewhere. > Probably the only way > is to document the directory. How should we document it? Writing man pages for the scripts and installing them is probably the minimum. Would there also need to be a LaTeX document for all the scripts, or is that overkill? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote: > [finding Tools/i18n/pygettext.py] > > You're right, I think Tools is probably a bad place for > > anything. If it's not part of the stdlib, I'll likely never > > find it. > > Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ > scripts could be put in __main__ sections of appropriate modules? So that > "python -m gettext" would be equivilant to "python Tools/i18n/pygettext.py"? > > (However, pyggettext.py is 22KB, which is a big addition to the module; not > everything in Tools/Scripts might be used enough for this, or have an > appopriate module to be put in either). > > Are there other ideas about how Tools/ could be improved? Either moving > things, or making it more likely that people will look there for scripts? > I assume that the Windows installer includes the Tools/ directory. If it doesn't that is one problem. =) Otherwise it is mostly a lack of advertisement and them not being installed by ``make install``. If you just download the soure and install you will never know the directory even exists. It needs to be made obvious to people that it is even there. Probably the only way is to document the directory. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
[finding Tools/i18n/pygettext.py] > You're right, I think Tools is probably a bad place for > anything. If it's not part of the stdlib, I'll likely never > find it. Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ scripts could be put in __main__ sections of appropriate modules? So that "python -m gettext" would be equivilant to "python Tools/i18n/pygettext.py"? (However, pyggettext.py is 22KB, which is a big addition to the module; not everything in Tools/Scripts might be used enough for this, or have an appopriate module to be put in either). Are there other ideas about how Tools/ could be improved? Either moving things, or making it more likely that people will look there for scripts? =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
