473,287 Members | 1,663 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,287 software developers and data experts.

gmpy 1.0 for python 2.4 alpha 2 Windows-packaged

Thanks to David Bolen, who did the build, I have been able to make
available a win32 packaging for gmpy 1.0 on python 2.4 alpha 2 (should
work on any later Python 2.4 as well, but I have no way to check it at
all). I can't reach sourceforge at the moment, so I have meanwhile put
the exe file up at:

http://www.aleax.it/Python/gmpy-1.0.win32-py2.4.exe

Users of both gmpy and python 2.4 on windows are invited to dowload and
install this, try it out, and let me know. There are a few known
glitches David tells me about:
"""
It seems to pass the tests (other than the scan ones noted)
with the exception of a bunch gmpy_test_rnd.rand due to changing
traceback output in 2.4. I also had to remove the use of doctest.master
since it looks like that's deprecated in 2.4 (it's no longer exported
by the module's __all__).
"""

Thanks to David, and to any users who can help me out, since I can't do
any testing on this build myself!
Alex
Jul 18 '05 #1
11 1732
[Alex Martelli]
...
There are a few known glitches David tells me about:
"""
It seems to pass the tests (other than the scan ones noted)
with the exception of a bunch gmpy_test_rnd.rand due to changing
traceback output in 2.4. I also had to remove the use of
doctest.master since it looks like that's deprecated in 2.4 (it's no
longer exported by the module's __all__).
"""


Ya, Edward Loper, Jim Fulton and I have made massive changes to
doctest for 2.4, refactoring it mercilessly.

doctest.master was a poorly documented attempt at starting to build a
framework for managing multiple tests, but as far as I knew it was
entirely unused -- all the heavy doctest users I knew about used
unittest frameworks, and so 2.4 has grown stronger ways of working
with unittest drivers instead. It's also grown much saner "doctest
runner" kinds of classes as part of that, as opposed to the old
doctest.master global. Under a hopeful belief that nobody was using
that anyway, I didn't gripe when Edward refactored it out of
existence. This is the first time we've heard that anyone *was* using
it!

I suppose we could hack one back in, but I'd rather volunteer to
rewrite the gmpy tests to use the stronger 2.4 gimmicks ...
Jul 18 '05 #2
Tim Peters <ti********@gmail.com> wrote:
...
traceback output in 2.4. I also had to remove the use of
doctest.master since it looks like that's deprecated in 2.4 (it's no
... doctest.master global. Under a hopeful belief that nobody was using
that anyway, I didn't gripe when Edward refactored it out of
existence. This is the first time we've heard that anyone *was* using
it!
I guess gmpy just wasn't on your radar...! If you have no need for its
multi-precision and special-functions support, that's unsurprising.

I suppose we could hack one back in, but I'd rather volunteer to
rewrite the gmpy tests to use the stronger 2.4 gimmicks ...


Thanks, your offer is welcome and gladly accepted -- as long as all the
tests keep running under 2.3 just as well, of course. There will be a
lot of 2.3 around for a long time -- for example, Apple isn't going to
change the Python version they use in Panther, which is 2.3, at least
until they come out with Tiger, say in May next year, and since, as
usual, they'll change $150 or so for the OS upgrade, many people will
just keep running Panther (and therefore Python 2.3). Etc, etc.

I do assume that it's easy to keep the hundreds of tests almost
unchanged, to avoid having to maintain them separately in two versions,
and support 2.3 and 2.4 with localized changes to the small spots where
the tests are run...?
Alex
Jul 18 '05 #3
al*****@yahoo.com (Alex Martelli) writes:
I do assume that it's easy to keep the hundreds of tests almost
unchanged, to avoid having to maintain them separately in two versions,
and support 2.3 and 2.4 with localized changes to the small spots where
the tests are run...?


At least when I ran it, the tests themselves (the doctest.testmod)
calls worked fine. The rand exceptions seemed to just be a difference
in reporting in 2.4, for example most of them were of the form:

- - - - - - - - - - - - - - - - - - - - - - - - -
Failure in example: r('error',1,2,3)
from line #2 of gmpy_test_rnd.rand in e:\usr\src\gmpy\test\gmpy_test_rnd.pyc
Expected:
Traceback (most recent call last):
File "<string>", line 1, in ?
TypeError: function takes exactly 2 arguments (4 given)
Got:
Traceback (most recent call last):
TypeError: function takes exactly 2 arguments (4 given)
- - - - - - - - - - - - - - - - - - - - - - - - -

However, when I try one of those tests interactively, Python 2.4 seems
to give me the "File" line too (indented, but it's also indented under
2.3, so I'm assuming the lack of indentation is unimportant to
doctest). So I guess I can't say for sure that this isn't something
impacted by a change in doctest. The doctest module docs for both 2.3
and 2.4 seem to imply it should only be checking the exception
type/value (the last line), so I guess I don't know why it's failing.
At least to me it seems clearly to be the right exception.

The one failure that I don't think you could easily anticipate is a
change in the actual exception message - for example the "r('shuf',
'astring')" test wants a TypeError saying "object doesn't support item
assignment", but 2.4 changes that to "object does not support item
assignment".

-- David
Jul 18 '05 #4
David Bolen <db**@fitlinxx.com> wrote:
...
The one failure that I don't think you could easily anticipate is a
change in the actual exception message - for example the "r('shuf',
'astring')" test wants a TypeError saying "object doesn't support item
assignment", but 2.4 changes that to "object does not support item
assignment".


Yeah, doctest IS prone to this sort of issue, sigh -- wording of error
messages keeps changing, in ways either subtle or major. I gather that
2.4 doctest has a "skip" indicator (an ellipsis I believe) to help with
that, but I don't want to break compatibilty with 2.3...
Alex
Jul 18 '05 #5
[David Bolen]
...
The one failure that I don't think you could easily anticipate is a
change in the actual exception message - for example the "r('shuf',
'astring')" test wants a TypeError saying "object doesn't support item
assignment", but 2.4 changes that to "object does not support item
assignment".
[Alex Martelli]
Yeah, doctest IS prone to this sort of issue, sigh -- wording of error
messages keeps changing, in ways either subtle or major. I gather that
2.4 doctest has a "skip" indicator (an ellipsis I believe) to help with
that, but I don't want to break compatibilty with 2.3...


Darn. The new doctest ELLIPSIS directive is a good long-term approach
to this, but you're right that it doesn't help you today. So, in the
*next* Python 2.4 prerelease, there will be a new
IGNORE_EXCEPTION_DETAIL directive. Then, e.g., this doctest passes
under 2.3.4 and 2.2.3, and will also pass in 2.4:
(1, 2)[3] = 'moo' #doctest: +IGNORE_EXCEPTION_DETAIL Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment

Since doctest directives didn't exist before 2.4, earlier Pythons view
them as comments, and insist on exact match. 2.4 will still insist on
seeing a TypeError, but won't care that "doesn't" has changed to "does
not" (or, for that matter, won't care if the actual detail is
"Congratulations, Anna and Alex!").

After Pythons prior to 2.4 become uninteresting, a less forgiving test
can be gotten via, e.g.,
(1, 2)[3] = 'moo' #doctest: +ELLISPSIS

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object does... support item assignment
Jul 18 '05 #6
[Tim Peters, on the demise of doctest.master]
Under a hopeful belief that nobody was using that anyway, I didn't
gripe when Edward refactored it out of existence. This is the first
time we've heard that anyone *was* using it!
[Alex Martelli]
I guess gmpy just wasn't on your radar...! If you have no need for its
multi-precision and special-functions support, that's unsurprising.
Since I live on Windows most of the time, I use Marc-Andre Lemburg's
mxNumber. That comes with a pre-built GMP, so is that much less for
me to screw up. I generally don't run package test suites on Windows
anyway (the odds that something is uniquely broken on my particular
WIndows box are too low).
I suppose we could hack one back in, but I'd rather volunteer to
rewrite the gmpy tests to use the stronger 2.4 gimmicks ...

Thanks, your offer is welcome and gladly accepted -- as long as all the
tests keep running under 2.3 just as well, of course. There will be a
lot of 2.3 around for a long time -- for example, Apple isn't going to
change the Python version they use in Panther, which is 2.3, at least
until they come out with Tiger, say in May next year, and since, as
usual, they'll change $150 or so for the OS upgrade, many people will
just keep running Panther (and therefore Python 2.3). Etc, etc.
Nothing against 2.3 here, it's simply a surprise that anyone was using
doctest.master. SourceForge is down at the moment, so I still don't
know whether gmpy's use was essential or shallow. If it was
essential, we'll have to hack a master workalike back in.

It could be too that many projects stumbled into using doctest.master,
but none yet bothered to try the 2.4 prereleases.
I do assume that it's easy to keep the hundreds of tests almost
unchanged, to avoid having to maintain them separately in two
versions, and support 2.3 and 2.4 with localized changes to the
small spots where the tests are run...?


It should be easy indeed. Edward Loper and Jim Fulton (by way of
Zope3) had thousands of doctests between them, and Python's test suite
has more than a few too. None of those doctests had to be changed in
any way. But none of them used doctest.master.

This next *may* be relevant to gmpy. I'm aware of it but haven't seen
an instance of it:

"""
1/0

Traceback (most recent call last):
abc
ZeroDivisionError: integer division or modulo by zero
"""

That doctest passes before 2.4, but no longer. I don't want to "fix"
that, either, if someone has code like this.

The problem is that a real traceback doesn't look like that. Python
always indents the lines between the initial "Traceback" line and the
exception detail line. This is important because 2.4 doctest supports
multiline exception details, so needs a way to guess where the
exception detail starts. Before 2.4, the exception detail had to fit
on a single line, and doctest's guess was simply "the exception detail
is the last line". In 2.4, it's "the exception detail starts with the
first line following the Traceback line that's not indented relative
to the Traceback line and that starts with an alphanumeric character".
That covers all real tracebacks, and the rare but known-to-exist
practice of representing omitted "File" lines with a left-aligned
ellipsis.

Bottom line is that such tests (if any exist) need to be rewritten.
Starting the "abc" lines with one or more blanks is sufficient so that
the test passes under all versions of doctest.
Jul 18 '05 #7
[David Bolen]
At least when I ran it, the tests themselves (the doctest.testmod)
calls worked fine. The rand exceptions seemed to just be a difference
in reporting in 2.4, for example most of them were of the form:

- - - - - - - - - - - - - - - - - - - - - - - - -
Failure in example: r('error',1,2,3)
from line #2 of gmpy_test_rnd.rand in e:\usr\src\gmpy\test\gmpy_test_rnd.pyc
Expected:
Traceback (most recent call last):
File "<string>", line 1, in ?
TypeError: function takes exactly 2 arguments (4 given)
Got:
Traceback (most recent call last):
TypeError: function takes exactly 2 arguments (4 given)
- - - - - - - - - - - - - - - - - - - - - - - - -

However, when I try one of those tests interactively, Python 2.4 seems
to give me the "File" line too (indented, but it's also indented under
2.3, so I'm assuming the lack of indentation is unimportant to
doctest).
It's actually crucial <wink>. I explained the gory details in another
posting. The bottom line is that the doctest should be changed to
indent the File line, just like it's always been indented in a real
traceback. doctest in 2.4 cares about this, in order to support an
important new feature (multiline exceptions). doctests prior to 2.4
didn't care, but they're perfectly happy whether or not that FIle line
is indented. 2.4 needs the indentation, in order to guess where the
exception part starts.
So I guess I can't say for sure that this isn't something
impacted by a change in doctest. The doctest module docs for
both 2.3 and 2.4 seem to imply it should only be checking the
exception type/value
That's true.
(the last line),


That's not -- in 2.4 it can span any number of lines. From the
current 2.4 docs:

Each line of the traceback stack (if present) must be indented further
than the first line of the example, or start with a non-alphanumeric
character. The first line following the traceback header indented the
same and starting with an alphanumeric is taken to be the start of
the exception detail. Of course this does the right thing for genuine
tracebacks.

Changed in version 2.4: The ability to handle a multi-line exception
detail was added.

The good news is that it should be dead easy to fix.
Jul 18 '05 #8
On Sat, 4 Sep 2004 20:09:38 -0400, Tim Peters <ti********@gmail.com> wrote:
[Tim Peters, on the demise of doctest.master]
Under a hopeful belief that nobody was using that anyway, I didn't
gripe when Edward refactored it out of existence. This is the first
time we've heard that anyone *was* using it!
[Alex Martelli]
I guess gmpy just wasn't on your radar...! If you have no need for its
multi-precision and special-functions support, that's unsurprising.


Since I live on Windows most of the time, I use Marc-Andre Lemburg's
mxNumber. That comes with a pre-built GMP, so is that much less for
me to screw up. I generally don't run package test suites on Windows
anyway (the odds that something is uniquely broken on my particular
WIndows box are too low).
I suppose we could hack one back in, but I'd rather volunteer to
rewrite the gmpy tests to use the stronger 2.4 gimmicks ...
Thanks, your offer is welcome and gladly accepted -- as long as all the
tests keep running under 2.3 just as well, of course. There will be a
lot of 2.3 around for a long time -- for example, Apple isn't going to
change the Python version they use in Panther, which is 2.3, at least
until they come out with Tiger, say in May next year, and since, as
usual, they'll change $150 or so for the OS upgrade, many people will
just keep running Panther (and therefore Python 2.3). Etc, etc.


Nothing against 2.3 here, it's simply a surprise that anyone was using
doctest.master. SourceForge is down at the moment, so I still don't
know whether gmpy's use was essential or shallow. If it was
essential, we'll have to hack a master workalike back in.

It could be too that many projects stumbled into using doctest.master,
but none yet bothered to try the 2.4 prereleases.
I do assume that it's easy to keep the hundreds of tests almost
unchanged, to avoid having to maintain them separately in two
versions, and support 2.3 and 2.4 with localized changes to the
small spots where the tests are run...?


It should be easy indeed. Edward Loper and Jim Fulton (by way of
Zope3) had thousands of doctests between them, and Python's test suite
has more than a few too. None of those doctests had to be changed in
any way. But none of them used doctest.master.

This next *may* be relevant to gmpy. I'm aware of it but haven't seen
an instance of it:

""" 1/0Traceback (most recent call last):
abc
ZeroDivisionError: integer division or modulo by zero
"""

That doctest passes before 2.4, but no longer. I don't want to "fix"
that, either, if someone has code like this.

The problem is that a real traceback doesn't look like that. Python
always indents the lines between the initial "Traceback" line and the
exception detail line. This is important because 2.4 doctest supports
multiline exception details, so needs a way to guess where the
exception detail starts. Before 2.4, the exception detail had to fit
on a single line, and doctest's guess was simply "the exception detail
is the last line". In 2.4, it's "the exception detail starts with the
first line following the Traceback line that's not indented relative
to the Traceback line and that starts with an alphanumeric character".
That covers all real tracebacks, and the rare but known-to-exist
practice of representing omitted "File" lines with a left-aligned
ellipsis.

Bottom line is that such tests (if any exist) need to be rewritten.
Starting the "abc" lines with one or more blanks is sufficient so that
the test passes under all versions of doctest.


Just a thought re traceback printed representation, while you're at it:
A traceback from an exception in a recursive call is apt to have repeated lines
that could be replaced by the first followed by an repeat count indication. E.g.,
def foo(x): 1.0/x; foo(x-1) ... foo(3) Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in foo
File "<stdin>", line 1, in foo
File "<stdin>", line 1, in foo
File "<stdin>", line 1, in foo
ZeroDivisionError: float division foo(1) Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in foo
File "<stdin>", line 1, in foo
ZeroDivisionError: float division foo(0)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in foo
ZeroDivisionError: float division

Repetitions are particularly useless when the stack blows totally, and you
get ~1k repetitions (how do you write a doc-test for the traceback of that?)

Just at thought. (I'm old enough to remember *gap* or such in line printer
listings with lots of otherwise repeating lines, before we had the luxury
of capturing hundreds of megabytes of printing to RAM on our own PCs ;-)

Regards,
Bengt Richter
Jul 18 '05 #9
Tim Peters <ti********@gmail.com> wrote:
IGNORE_EXCEPTION_DETAIL directive. Then, e.g., this doctest passes
under 2.3.4 and 2.2.3, and will also pass in 2.4:
(1, 2)[3] = 'moo' #doctest: +IGNORE_EXCEPTION_DETAIL Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment

Since doctest directives didn't exist before 2.4, earlier Pythons view
them as comments, and insist on exact match. 2.4 will still insist on
seeing a TypeError, but won't care that "doesn't" has changed to "does
GREAT solution!
not" (or, for that matter, won't care if the actual detail is
"Congratulations, Anna and Alex!").
Heh -- thanks!

After Pythons prior to 2.4 become uninteresting, a less forgiving test
can be gotten via, e.g.,
(1, 2)[3] = 'moo' #doctest: +ELLISPSIS

Wow -- typo-tolerant, too?-)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object does... support item assignment


Right, unless 2.5 changes the error text to "objects of type tuple do
not support item assignment" or some other clarificatory rewording, of
course:-). In practice, my doctests that are meant to survive across
Python releases will become heavy users of IGNORE_EXCEPTION_DETAIL!-)
Alex
Jul 18 '05 #10
Tim Peters <ti********@gmail.com> wrote:
[Tim Peters, on the demise of doctest.master]
Under a hopeful belief that nobody was using that anyway, I didn't
gripe when Edward refactored it out of existence. This is the first
time we've heard that anyone *was* using it!
[Alex Martelli]
I guess gmpy just wasn't on your radar...! If you have no need for its
multi-precision and special-functions support, that's unsurprising.
Since I live on Windows most of the time, I use Marc-Andre Lemburg's
mxNumber. That comes with a pre-built GMP, so is that much less for


So does gmpy in the prebuilt-for-Windows version, btw. I may even have
snagged that from Marc Andre's package at some time in the past...
me to screw up. I generally don't run package test suites on Windows
anyway (the odds that something is uniquely broken on my particular
WIndows box are too low).
Hmmm -- what you mean by Windows and what I mean by Windows must be very
different OS's. Has DLL Hell disappeared since I finally stopped
working as a Windows guru and turned to Linux, Mac OS X, OpenBSD and
other OS's...?-)

I suppose we could hack one back in, but I'd rather volunteer to
rewrite the gmpy tests to use the stronger 2.4 gimmicks ...
Thanks, your offer is welcome and gladly accepted -- as long as all the
tests keep running under 2.3 just as well, of course. There will be a
lot of 2.3 around for a long time -- for example, Apple isn't going to
change the Python version they use in Panther, which is 2.3, at least
until they come out with Tiger, say in May next year, and since, as
usual, they'll change $150 or so for the OS upgrade, many people will
just keep running Panther (and therefore Python 2.3). Etc, etc.


Nothing against 2.3 here, it's simply a surprise that anyone was using
doctest.master. SourceForge is down at the moment, so I still don't
know whether gmpy's use was essential or shallow. If it was
essential, we'll have to hack a master workalike back in.


Probably shallow. Anyway, I'll be glad to mail you a gmpy package if SF
keeps giving problems, let me know!
It could be too that many projects stumbled into using doctest.master,
but none yet bothered to try the 2.4 prereleases.
I hadn't, for example -- even though I've been current on 2.4 for a long
time, I hadn't thought of building gmpy for it (shame on me!).

I do assume that it's easy to keep the hundreds of tests almost
unchanged, to avoid having to maintain them separately in two
versions, and support 2.3 and 2.4 with localized changes to the
small spots where the tests are run...?


It should be easy indeed. Edward Loper and Jim Fulton (by way of
Zope3) had thousands of doctests between them, and Python's test suite
has more than a few too. None of those doctests had to be changed in
any way. But none of them used doctest.master.


Ah... well, let's hope my use was indeed shallow!

This next *may* be relevant to gmpy. I'm aware of it but haven't seen
an instance of it:

""" 1/0
Traceback (most recent call last):
abc
ZeroDivisionError: integer division or modulo by zero
"""

That doctest passes before 2.4, but no longer. I don't want to "fix"
that, either, if someone has code like this.

... Bottom line is that such tests (if any exist) need to be rewritten.
Starting the "abc" lines with one or more blanks is sufficient so that
the test passes under all versions of doctest.


OK, inserting blanks if needed doesn't seem too difficult a fix, I
agree!
Alex
Jul 18 '05 #11
In article <ma**************************************@python.o rg>,
Tim Peters <ti********@gmail.com> wrote:

Darn. The new doctest ELLIPSIS directive is a good long-term approach
to this, but you're right that it doesn't help you today. So, in the
*next* Python 2.4 prerelease, there will be a new
IGNORE_EXCEPTION_DETAIL directive. Then, e.g., this doctest passes
under 2.3.4 and 2.2.3, and will also pass in 2.4:
(1, 2)[3] = 'moo' #doctest: +IGNORE_EXCEPTION_DETAIL

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment

Since doctest directives didn't exist before 2.4, earlier Pythons view
them as comments, and insist on exact match. 2.4 will still insist on
seeing a TypeError, but won't care that "doesn't" has changed to "does
not" (or, for that matter, won't care if the actual detail is
"Congratulations, Anna and Alex!").


Huh. The advice I've always seen is, "Never rely on the text of an
exception -- it can change even in bugfix releases."
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"A foolish consistency is the hobgoblin of little minds, adored by little
statesmen and philosophers and divines." --Ralph Waldo Emerson
Jul 18 '05 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
by: Jean-Pierre Andreaux | last post by:
Gmpy module was a wrapper of the GNU MP library. It seems that no evolution is done on this module since 2001. Indeed, Gmpy is not supported in Python 2.2 nor 2.3. My question is the following:...
2
by: Mensanator | last post by:
In the program that follows, I get the following warning message: collatz_.py:37: RuntimeWarning: tp_compare didn't return -1, 0 or 1 while b>1: In this case, b is a gmpy.mpz number. The...
3
by: mensanator | last post by:
Since the following discussion took place (unresolved), ...
22
by: Alex Martelli | last post by:
I have fixed almost all of the outstanding bugreports and feature request for gmpy: divm doesn't leak memory any more, truediv and floordiv are implemented for all types, etc -- in the current CVS...
0
by: Alex Martelli | last post by:
I've added to gmpy.sf.net two binary packages of gmpy for Mac OS X 10.4, one for the Python 2.3.5 that comes with the system and one for Bob Ippolito's build of 2.4.1. They still need GMP to be...
3
by: mensanator | last post by:
## Holy Mother of Pearl! ## ## >>> for i in range(10): ## for j in range(10): ## print '%4d' % (gmpy.mpz(i)*gmpy.mpz(j)), ## print ## ## ## ...
3
by: zakad | last post by:
python 2.5.2 ubuntu 8.04 LTS (1) I find that python/gmpy is about 3 times slower than c++/gmp. Is this the general experience, or am I doing something wrong? (2) I am unable to understand the...
7
by: | last post by:
Hi, I just stumbled upon the following issue (I am running Debian): $ python Python 2.5.2 (r252:60911, Sep 29 2008, 21:15:13) on linux2 Type "help", "copyright", "credits" or "license" for...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.