I'm working on a checkbook program and I noticed that if you use a REAL
field and store 1.00 into it it only stores the 1 so I just use text now
to store numbers.
JT
On 4/22/2014 10:23 AM, Gene Heskett wrote:
What sort of contortions are required to fully recover a number stored in
SQLite as
On Mon, Apr 21, 2014 at 1:47 PM, Marius Liebenberg
mar...@mastercut.co.zawrote:
Andy
Have a look at this work. Maybe a good solution.
https://github.com/bitsnbytes7c8/MegatronDB
What's wrong with using proven, production-style databases that work well
large or small? MySQL and postgresql
On Mon, Apr 21, 2014 at 2:02 PM, andy pugh bodge...@gmail.com wrote:
Possibly.
The real work is in working out everywhere that tool data is used, and
when changes get committed back to the DB.
The details of the storage can be decided later (if sqlite proves to
be not ideal).
--
atp
On 22 April 2014 10:20, Mark Wendt wendt.m...@gmail.com wrote:
Why not leave the choice up to the end user as to which database they'd
prefer to use?
This would work if the query language was 100% identical. I don't know
if it is.
--
atp
If you can't fix it, you don't own it.
With MySql you need to install LAMP and with postgresql it looks like
you have to have a server running and create a user that can log into
the server or something like that. Sqlite requires non of that. I've
used MySql for web based PHP applications and Sqlite for local Python
applications.
On Tue, Apr 22, 2014 at 6:36 AM, andy pugh bodge...@gmail.com wrote:
On 22 April 2014 10:20, Mark Wendt wendt.m...@gmail.com wrote:
Why not leave the choice up to the end user as to which database they'd
prefer to use?
This would work if the query language was 100% identical. I don't know
On Tue, 22 Apr 2014, Mark Wendt wrote:
On Tue, Apr 22, 2014 at 6:36 AM, andy pugh bodge...@gmail.com wrote:
On 22 April 2014 10:20, Mark Wendt wendt.m...@gmail.com wrote:
Why not leave the choice up to the end user as to which database they'd
prefer to use?
This would work if the query
On Tuesday 22 April 2014 11:22:14 John Thornton did opine:
With MySql you need to install LAMP and with postgresql it looks like
you have to have a server running and create a user that can log into
the server or something like that. Sqlite requires non of that. I've
used MySql for web based
On Tuesday 22 April 2014 11:22:14 John Thornton did opine:
With MySql you need to install LAMP and with postgresql it looks like
you have to have a server running and create a user that can log into
the server or something like that. Sqlite requires non of that. I've
used MySql for web based
On 22 April 2014 16:23, Gene Heskett ghesk...@wdtv.com wrote:
What sort of contortions are required to fully recover a number stored in
SQLite as text?
Why would you need to?
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
On Tuesday 22 April 2014 12:38:24 andy pugh did opine:
On 22 April 2014 16:23, Gene Heskett ghesk...@wdtv.com wrote:
What sort of contortions are required to fully recover a number stored
in SQLite as text?
Why would you need to?
Something in the back of my mind, possibly from a past
On 21 April 2014 03:30, Kirk Wallace kwall...@wallacecompany.com wrote:
I did start on making the tool table a lot cleverer. It would be a
database (which means that you can actually add any data fields you
like for your own purposes, LinuxCNC will just ignore things it
doesn't know how to
On Mon, Apr 21, 2014 at 4:32 AM, andy pugh bodge...@gmail.com wrote:
On 21 April 2014 03:30, Kirk Wallace kwall...@wallacecompany.com wrote:
I did start on making the tool table a lot cleverer. It would be a
database (which means that you can actually add any data fields you
like for your
On 21 April 2014 10:10, Mark Wendt wendt.m...@gmail.com wrote:
Ugh. Stay away from SQLite. That's a one-user, build it in your home
directory, terribly slow, resource hog. MySQL or PostgreSQL are much
better databases. You can optimize them much easier and better,
It's a tool table. Just
On Mon, Apr 21, 2014 at 5:37 AM, andy pugh bodge...@gmail.com wrote:
On 21 April 2014 10:10, Mark Wendt wendt.m...@gmail.com wrote:
Ugh. Stay away from SQLite. That's a one-user, build it in your home
directory, terribly slow, resource hog. MySQL or PostgreSQL are much
better
On 21 April 2014 10:43, Mark Wendt wendt.m...@gmail.com wrote:
It's a tool table. Just how big and busy do you anticipate it getting?
It depends. For somebody like me, not very big, but for somebody like
Stuart, I imagine it might grow a bit.
I imagine even MPM only have hundreds of tools
On Mon, Apr 21, 2014 at 5:52 AM, andy pugh bodge...@gmail.com wrote:
On 21 April 2014 10:43, Mark Wendt wendt.m...@gmail.com wrote:
It's a tool table. Just how big and busy do you anticipate it getting?
It depends. For somebody like me, not very big, but for somebody like
Stuart, I
Whats wrong with a file based tool table. It is easier for the layman to
maintain offline as well.
On 2014-04-21 11:37, andy pugh wrote:
On 21 April 2014 10:10, Mark Wendt wendt.m...@gmail.com wrote:
Ugh. Stay away from SQLite. That's a one-user, build it in your home
directory, terribly
On 21 April 2014 11:33, Marius Liebenberg mar...@mastercut.co.za wrote:
Whats wrong with a file based tool table. It is easier for the layman to
maintain offline as well.
A simple flat file has to make assumptions about what data can be
stored. Specifically it would have to make assumptions
I understand now. I have to agree with you that the SQlite option will
be the least resource intensive thing to use.
I used to use a file based RDBS a long time ago that was very easy to
implement with a very small footprint, but I cannot seem to find any
reference to it anywhere.
On
Andy
Have a look at this work. Maybe a good solution.
https://github.com/bitsnbytes7c8/MegatronDB
On 2014-04-21 17:37, andy pugh wrote:
On 21 April 2014 11:33, Marius Liebenberg mar...@mastercut.co.za wrote:
Whats wrong with a file based tool table. It is easier for the layman to
maintain
On 21 April 2014 18:47, Marius Liebenberg mar...@mastercut.co.za wrote:
Andy
Have a look at this work. Maybe a good solution.
https://github.com/bitsnbytes7c8/MegatronDB
Possibly.
The real work is in working out everywhere that tool data is used, and
when changes get committed back to the DB.
It would be interesting to know if there are any examples of controllers
with mill tool tables that include tool shape. The lathe has tip radius,
plus front, back angles and orientation. I would like to have end mill
corner radius or v angle and full depth diameter. I'm wondering if there
is
To: Enhanced Machine Controller (EMC)
Subject: [Emc-users] Tool Shape
It would be interesting to know if there are any examples of controllers
with mill tool tables that include tool shape. The lathe has tip radius,
plus front, back angles and orientation. I would like to have end mill
corner radius
To: Enhanced Machine Controller (EMC)
Subject: [Emc-users] Tool Shape
It would be interesting to know if there are any examples of controllers
with mill tool tables that include tool shape. The lathe has tip radius,
plus front, back angles and orientation. I would like to have end mill
corner radius
Kirk,
Take a look at the tool description(s) available in APT.
If necessary just download the whole package. The guys did a really good
job of html docs. :-)
How you adapt that to something else I have no idea. ;-)
Dave
On Sun, 2014-04-20 at 08:31 -0700, Kirk Wallace wrote:
It would be
On 04/20/2014 09:28 AM, Pete Matos wrote:
Yeah I know the Haas has the diameter column as well as wear column for the
TLO. I am quite surprised that LinuxCNC does not have these most simple
items let alone radius and shape comp.
Good luck man. I would love to see wear columns for each of the two mill
related offsets length and diameter. Similar to the Haas and many other
controls where you just input the base number into the length and diameter
columns and then input any adjustments you make at the control into the
wear
On 20 April 2014 17:28, Pete Matos petefro...@gmail.com wrote:
Yeah I know the Haas has the diameter column as well as wear column for the
TLO. I am quite surprised that LinuxCNC does not have these most simple
items let alone radius and shape comp.
The CNC controller doesn't know enough
From: andy pugh [bodge...@gmail.com]
Sent: Sunday, April 20, 2014 3:48 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Tool Shape
On 20 April 2014 17:28, Pete Matos petefro...@gmail.com wrote:
Yeah I know the Haas has the diameter column as well as wear column
On 04/20/2014 12:54 PM, Pete Matos wrote:
Good luck man. I would love to see wear columns for each of the two mill
related offsets length and diameter. Similar to the Haas and many other
controls where you just input the base number into the length and diameter
A soon to be released lathe
On 04/20/2014 03:48 PM, andy pugh wrote:
On 20 April 2014 17:28, Pete Matos petefro...@gmail.com wrote:
Yeah I know the Haas has the diameter column as well as wear column for the
TLO. I am quite surprised that LinuxCNC does not have these most simple
items let alone radius and shape comp.
32 matches
Mail list logo
