<church_>
guys: any hints how might i approach need to hull 3 rotate extrudes together? https://bpa.st/JZIQ while i can hull together two of them, that are in "one plane", prior rotate_extrude, i'm out of ideas, how to add in 3rd at offset, without hull filling up concavities of rotate_extrudes, leaving triangle with rounded outside :/
snaked has joined #openscad
<church_>
i cannot also hull together all three prior rotate_extrude, as that would be 3d object on which it will refuse to run
Guest40 has joined #openscad
Guest40 has quit [Client Quit]
<InPhase>
church_: Poorly defined problem statement. What should it even look like in the vicinity of x=-10?
<InPhase>
church_: There's no single definition for how to merge the 3 circles at that x value, with their different terminal y values of 0 and -7.5, while not hulling the inner parts of the shape either.
ccox has quit [Ping timeout: 268 seconds]
<InPhase>
church_: There is the definiton of a hull-sweep that J25k65 has tons of code examples of. It is one of his specialties. This involves hulling together overlapping stepwise slivers and then unioning them. Like for yours, a from 0 to 90, and do a 1.1 degree long rotate extrude at a=0, hull that. Then do a 1.1 degree long rotate extrude at a=1, hull that. Finally a 1 degree long sliver at a=89, and
<InPhase>
hull that.
<InPhase>
But if that's not what you mean, you must define it clearer before it can be solved.
ccox has joined #openscad
guerd has quit [Read error: Connection reset by peer]
foul_owl has quit [Ping timeout: 244 seconds]
foul_owl has joined #openscad
lastrodamo has joined #openscad
guso78k has joined #openscad
stealth_ has quit [Quit: Leaving]
<gbruno>
[github] damienmarchal synchronize pull request #5630 ([UX] Add of the "Jump to..." navigation method and clean the "Window" menu of its duplicated elements) https://github.com/openscad/openscad/pull/5630
<church_>
InPhase: i thought of hulling individual steps/segments, but couldn't found rotate_extrude analog by segments to use for that. Hence thought if maybe there are alternative ways of hulling y spaced apart concave bits
<church_>
if even with differing Y, X were same (4x rotate extrudes spaced in rounded corner square fashion at base,), then i guess it would be thing of doing interference of two pairs of rounded extrusions that are extended past where other extrusions are
<church_>
but this approach probably won't work with both Y & X different, where there is triangular-ish both X & Y spacing apart
misterfish has quit [Ping timeout: 245 seconds]
mtm has joined #openscad
<InPhase>
church_: You can also hull sweep the top two, and then hull sweep the bottom two, then there is no triangle.
<InPhase>
church_: As I said, there's no one definition for this, but that is another definition. The hull of slivers of the most adjacent components at each parameterised step.
<church_>
InPhase: can you point me to some example of rotate_extrude by segments? no need for extra stuff like hulling with others and such, just what formulas to use for translation/rotation of rotate extruded object per step, "analogue of rotate_extrude by segments"
<InPhase>
church_: It's just about making the segment length smaller, but with overlap, and rotating into position with an added rotate.
<church_>
it still seems simpler then sin/cos calculating translate/rotate values of each segment
<church_>
thanks for your example
<InPhase>
As you can see, there can be some surprising eccentricities to the shape there on the inner part. But those are not errors, just a byproduct of the definition of the shape.
<church_>
i can just fill the rest with another rotate_extrude of pre-extrude hulled together two rearmost circles, and it will be done
Reisga2449 has quit [Ping timeout: 260 seconds]
<InPhase>
church_: There's also the more satisfying pipe-joiner approach, where you repeat calculate the i and the i+1 element and hull those: https://bpa.st/XCNA
<InPhase>
This approach is tricky, because if you don't calculate exact i and i+1 elements, you get micro defects all along and it looks terrible.
<church_>
InPhase: your first variant was almost 100% what i needed. My goal was https://bpa.st/KALQ , (which is as your first variant, but two separate hulls moved under single per segment)
<InPhase>
I see.
<InPhase>
And of course that cleans up real nice if you drop $fa=1; $fs=0.4; at the top.
<church_>
about only thing that maybe can be further tuned, dynamically adjustable count of segments, but it looks smooth as is with 90 degments, so maybe i shouldn't bother
<church_>
$fa/$fs i have adjusted model-wide in beginning in constants. this just single element i didn't know how to effectively approach, for which thanks again
<InPhase>
Switching that to for (a=[0:2:88]) { alen=(a==88)?2:2.01; provides size symmetry with $fa=1; $fs=0.4;
stealth_ has joined #openscad
guso78k has joined #openscad
L29Ah has left #openscad [#openscad]
noonien808310429 has joined #openscad
L29Ah has joined #openscad
snaked has quit [Remote host closed the connection]
<gbruno>
[github] t-paul pushed 1 additions 9 modifications (Python: Sphere, Cylinder, Color, Rotation - Node cloning for safe tree handling in python - Locking support for python interpreter --------- Co-authored-by: Guenther Sohler <guenther.sohler@photeon.com>) https://github.com/openscad/openscad/commit/c3d173854efafdc95aa9ff962e5a69b69e7f1590
<church_>
InPhase: i just changed to: smidge=.001;xtrang=90;steps=max(4,round(xtrang/360*2*PI*rotrad/$fs/15)*15);step=xtrang/steps; for(a[0:step:xtrang-step]) { alen=(a==xtrang-step)?step:step+smidge;
<church_>
(so that as i change $fs globally to adjust quality, step count dynamically changes, depending on extrusion radius and angle)
<InPhase>
A good plan. :) This is the right way to do it. It just takes a notch more thinking, best reserved for a late stage step.
<InPhase>
church_: Note that with those a == xrang-step type checks, you can benefit from doing an ai integer range, and then calculating a from ai right after it, so that you can check an ai being the last integer. This avoids floating point inaccuracies failing out on that conditional check.
<InPhase>
Obviously it will only break by a "smidge" here, but if you're trying to make it exact ended, the integer will give you that reliability.
<InPhase>
s/an ai being/on ai being/
<church_>
shouldn't my rounding in dividable by 15 also help?
<InPhase>
Probably in this case, yes.
<InPhase>
I usually just do the integer thing to decouple from mysterious dependencies like that.
<InPhase>
I skipped it for the initial demo, since I used integer angle steps. But then when I go to parameterize in my own code, I insert the integer indirection. And usually by the step of just appending i to the variable name, and setting the original from it right after that, so the following tested code doesn't change.
<InPhase>
Nice and patterned.
<church_>
hmm, interesting. simplifies things and avoids potential problems (mentioned floating p-t inaccuracies)
<InPhase>
It also guarantees even spacing of elements more naturally.
<InPhase>
Or at least, with less thinking.
<InPhase>
N=73; for (ai=[0:N-1]) { step = 90/N; a = ai*step; echo(a, a+step); }
<church_>
you guys should at some point publish not just docs how things/functions and other bits in openscad work, but also best practices and useful tips/hacks :)
<InPhase>
And if you want to be more precise... Always do it as: a2 = (ai+1)*step; so that a2 is calculated by the same floating point computation as a of the next loop, meaning a2 is guaranteed to equal a of the next loop.
<teepee>
we do
<teepee>
nobody read them ;-)
<InPhase>
Frequently Unread Answers.
<church_>
well, eg. that hack about autoselecting font by unicode character code i heard first here. this integerizing also sounds useful. bits like these ..
<teepee>
that's a 10 day old tip? did you know, it's a wiki, you can add it too :)
<InPhase>
church_: There's an illustration of this principle in the 2024 calendar in teepee's n_gon function. Although it creates the problem of how does one go about finding a tip without knowing where to look? :)
<InPhase>
church_: This is hiding on Day 12
<teepee>
well, indexing those and making a nice page is on my list
<church_>
how minkowski managed to make it's way to tips & tricks? :)
<teepee>
for a couple of years
<InPhase>
Tip! Don't use minkowski. ;)
<church_>
100%
<InPhase>
Except sometimes, while pinching your nose.
<teepee>
if nobody steps up, it may take another couple of years to happen, who knows...
<church_>
by my experience minkowski can be used only for 2d or very basic simple shapes. then it's perf impact can be ignored, and that's it
<InPhase>
church_: Honestly, I personally don't have a mental model for which subset of users would actually read our Tips and Tricks on the wiki, so I haven't been editing it very much.
<InPhase>
church_: I think I generate a lot of useful tips, but organizing them and understanding who would have looked where for them, is kind of a different problem.
<InPhase>
church_: But one think I made sure to do when I started out, is to try to edit documentation every time I tried to find something somewhere, didn't find it, and then later figured it out.
<teepee>
guso78: the appimage complains about not finding python, any idea why? did you have any issues?
<church_>
InPhase: i possibly do it wrong, but usually try to formulate well search terms, google how others did something similar, to lessen reinventing bicycle, and adapt code
<InPhase>
church_: That way the documentation would have served me, and thus, will serve people like me.
<InPhase>
church_: So my advice to you is to do the same, and every time you failed to find something that you looked for, and later found it, try to fix it up so you would have found it. I think this is a really good formula, and if a good set of people follow it while learning, the docs will get amazing.
<InPhase>
church_: This is based on the philosophy that you represent a class of people like yourself, with a certain background, who try to solve problems the way you do.
<guso78k>
teepee, yes, for python to run in appimage, it need to find its std libs. you need to copy them in + you need to set path to them, i can assemble some snippets
<teepee>
hmm, the libs should be there, let me double check
<guso78k>
during python init time, any of its path need to point to a valid std lib
<teepee>
I'm also upgrading to 22.04 as 20.04 is out of support soon and github already tossed it
<guso78k>
after i prepared an "extra copy" it worked better, but we improve quality
<teepee>
I think what we finally need is a way of telling it to create a venv
<teepee>
not sure what is needed to implement that
<InPhase>
Hmm. Should the venv's be shared across release versions?
<InPhase>
One venv per snapshot would be a nightmare. But one venv for different release versions might also cause future problems.
<InPhase>
I mean sharing one venv between different release versions might cause future problems.
<InPhase>
Python environments and cross-compatibility can be complicated. But probably different releases will ship with different requirements.
<InPhase>
Hmmm... guso78k, what if there's a venv version marker that gets updated as requirements change in the future?
<InPhase>
guso78k: That way as snapshots share identical requirements, they share a venv. But if this changes, distinct venvs are used, by dev update of this version marker at each change.
<teepee>
oh, right python deploy plugin, that's waaaay too obvious :)
<guso78k>
teepee, but its a different author
<teepee>
different?
<guso78k>
InPhase, dont have experience there, i neither use vens
<teepee>
I guess for start, we can use the plugin as that worked for guso78
<InPhase>
Because if we can nest appimages, then it's just using an already solved problem.
<teepee>
guso78: ah, yes, I saw those
<teepee>
no, I don't think you can nest those, you can extract and combine I think
<guso78k>
teepee, will you maintain the OpenSCADPy separate buidl target ?
<teepee>
not really separate, but maybe a minimal version without for some special cases
<teepee>
at this point it's enabled in the OBS distro builds, Snap and Flatpak
<guso78k>
right now i am having a real hard time to separate mxe-mingw from OpenSCADPy
<teepee>
that will have to wait, my day is not long enough
<teepee>
maybe someone with some spare time cares to help while the linux stuff is in progress
<teepee>
same for macos
misterfish has quit [Ping timeout: 252 seconds]
<TheAssassin>
InPhase: you can
<teepee>
oh, you can nest appimages? interesting, I did not expect that
<TheAssassin>
and yeah, that linuxdeploy plugin should work
<TheAssassin>
sorry, I can't read the entire backlog, so please ask direct questions if you need feedback
<teepee>
it's flagged as not maintained anymore
<TheAssassin>
teepee: well I'm not aware of any limitation that'd prevent you from running an AppImage in an AppImage, but I'd have to check
<TheAssassin>
call it an educated guess
<teepee>
nice, good to know, yeah final tests are always needed :)
<TheAssassin>
I think one of the reasons not to do it is to support --appimage-extract-and-run, when nesting you'd have to use the env var
<teepee>
with that python plugin "not maintained" anymore, the quesion would be if there is any alternative known
<TheAssassin>
I think that's actually worth an issue on the spec, the runtime should export that setting
<TheAssassin>
yeah, I wasn't aware of that
<TheAssassin>
I usually use my own linuxdeploy-plugin-conda to create a portable miniconda environment
<teepee>
the docs in the repo point to some appimages shipping python in working way, but did not directly mention a replacement for use in other apps
<guso78k>
the python plugin does nothing fancy. its just a script which automatically downloads a certain python version and compiles it.
<teepee>
I've never used conda
<teepee>
would that be an option for openscad too?
<TheAssassin>
probably, although I personally don't use it in combination with other software
<teepee>
like we (well guso78k did) add pyhon as additional language to the app linking to the python lib
<TheAssassin>
I think we had at least two people bundle a Python _interpreter_ (kinda standalone) using the conda plugin, i.e., software that doesn't link against libpython
<teepee>
at some point it would then make sense to give people the means to install and use additional packages too
<TheAssassin>
the Python plugin had some bug fixes that never made it into the conda plugin because I never needed that
<TheAssassin>
I think it's kinda like a more streamlined way of bundling python
<guso78k>
yes, i was able to run python pip from within openscad. this has the advantage that automatically the correct python packages are installed
<teepee>
hmm, I need to do some reading then what conda does
<TheAssassin>
guso78k: the issue I see with that approach is that you're polluting the user's standard site_packages
L29Ah has left #openscad [#openscad]
<TheAssassin>
w/o a virtualenv of any kind, this is problematic
<TheAssassin>
you can't write to the AppImage, though
<teepee>
just brainstorming... ideally we would have a menu entry "select / create virtual env for python"
<TheAssassin>
the portable approach might be to just create a venv with a bundled python in some place and keep track of the installed stuff separately so you can always recreate the env with a different python
<TheAssassin>
(e.g., when upgrading from Python X to Y in the AppImage)
<guso78k>
yes, i see, but normal guys dont use more than one python version, so all site-pacakges ideally contain the same package set
<teepee>
not possible on linux unless using the distro builds
<ali1234>
it should not really rely on the system python at all
<TheAssassin>
that's not the point. your plugins' dependencies might just interfere with stuff people already have set up
<teepee>
the AppImage and Snap/Flatpak too will likely have a different python
<TheAssassin>
yeah depending on the system libpython and site_packages is a bad idea
<ali1234>
it's not actually the python executable it is relying on, it is the standard library
<ali1234>
so whatever python it was built for has to match the python on the system
<teepee>
right, so we need to package venv and pip
<TheAssassin>
you can't predict what's going on on people's systems, so you want to bundle a Python and you probably want to maintain your own portable environment on the user's system
<teepee>
yes, I think so
<ali1234>
no you need to package the whole standard library
<TheAssassin>
you need to package libpython, too, and a (portable) Python interpreter, something you can achieve with python_appimage
<TheAssassin>
yeah, that, too
<TheAssassin>
you need a complete Python distribution and with that you can create your user's venv
<teepee>
fine by me :)
<ali1234>
don't need the interpreter executable afaik
<TheAssassin>
I presume the increase in file size doesn't matter anyway
<TheAssassin>
ali1234: true, but then you need to use libpython to create the venv, which is totally doable
<ali1234>
i don't follow
<ali1234>
users won't need to do that?
<TheAssassin>
nope, but openscad needs to do that
<teepee>
so workflow would be
<TheAssassin>
thinking about it I realized you anyway need to link against libpython and implement some sort of API which means that running venv via libpython isn't that much of an additional effort as compared to using a subprocess
<teepee>
1) install openscad
<teepee>
2) use minimal python to create designs without additional packages is fine
<teepee>
3) want to use external stuff
<ali1234>
check out what the blender snap does
<ali1234>
in eg /snap/blender/current/4.3/python/
<teepee>
4) select folder and "create venv"
<teepee>
5) have some means to call pip to install / uninstall packages
<ali1234>
okay so this is a problem that is also shared with blender
<teepee>
I would assume all app that shall allow installing external packages
<TheAssassin>
ali1234: hm, thinking about it again, to create the venv, you may need to include a python interpreter
<ali1234>
you can create a venv, activate it, install pip all from python code.. and openscad can run python code now
<teepee>
but "python3 -m venv" is just calling the python code, no?
<ali1234>
yes
<teepee>
so it should work with libpython too?
<ali1234>
of course
<ali1234>
this is why you don't need a separate interpreter... openscad already is one
<ali1234>
blender does ship one though, just because it's easier
<teepee>
exactly, a very special one not exposing the cli
<teepee>
well, worst case we just package one, but I'd like to not do that for cross plaform reasons
<ali1234>
yes, which is exactly what blender does. you can't do "blender -m venv" although there are some different python-related CLI options to do... stuff
<teepee>
python calling the venv files differently is bad enough
<ali1234>
yes, packaging multiple executables does not make sense for appimages
<TheAssassin>
ali1234: venv copies the bundled interpreter from your python dir, though
<ali1234>
it makes a symlink
<ali1234>
which would just be a symlink to openscad.exe or w/e
<TheAssassin>
ok well then a broken symlink wouldnt matter either
<teepee>
and we have the python-pre-config under code control anyway
<ali1234>
the blender snap doesn't actually expose its python.exe, and i still managed to set up a venv with it
<teepee>
as openscad is basically the interpreter too
<teepee>
for some reason enabling openscad python support in Snap did just work, that was a surprise
<TheAssassin>
well interesting stuff
<TheAssassin>
either way that's very premature optimization isn't it
<teepee>
but no external packages yet, obviously
<ali1234>
unfortunately graphics acceleration is still broken on snaps for me
<teepee>
agreed, getting a workflow to actually work is the first step :)
<ali1234>
otherwise i'd definitely poke at this
<teepee>
try with the appimage? or flatpak? or even just with the normal build?
<teepee>
guso78 already has a huge backlog of python related changes that we would want to merge
<teepee>
but the build and distribution topics have to be solved too
<TheAssassin>
the method with libpython and some bundled site_packages should be relatively universal
<TheAssassin>
you can configure that path with some env var if needed
<ali1234>
teepee: i can try any of those if they are python enabled
<TheAssassin>
I also think that ld-p-python has some info on that
<teepee>
ali1234: Snap, Flatpak and OBS distro builds are enabled
<teepee>
I'm still working on the AppImage as I also want to migrate to 22.04 from the current 20.04
<ali1234>
i tried guso78's appimage from pythonscad.org but it wants python 3.11 and i have 3.12
<teepee>
and that's exactly what we need to get working
<ali1234>
right
<teepee>
so you can create a venv based on the 3.11 in openscad
<ali1234>
and the sensible way is to bundle the python libraries into the appimage
<ali1234>
i mean .py files that comprise the standard library
<ali1234>
when you run it, it actually lists all the places it looks for those files, which includes inside the appimage filesystem itself
L29Ah has joined #openscad
<teepee>
yep, that's what we need to get sorted, what to bundle and how to then let it optionally create a venv (or whatever is needed)
<ali1234>
fixing this should just be a matter of copying the files inside the appimage
<ali1234>
venvs are a separate problem
<teepee>
yes
<ali1234>
because the process of creating those is entirely python code. as long as you can run python code, you can make venvs
<teepee>
first step should get python working inside the appimage
<teepee>
venv would allow external packages in addition
<ali1234>
it might not be super easy to do, but it is possible
<ali1234>
making it easy is a user experience thing
<teepee>
true, but we certainly want that
<teepee>
that's one of the main points of openscad :)
<ali1234>
and a user experience thing should not be tied to the way it is packaged :)
<teepee>
mostly, it's not 100% possible, especially for the container formats
<teepee>
like "store on /ext-nas" is just not happening on Snap
<teepee>
and needs magic stuff for Flatpak but at least is possible
<ali1234>
where can i find the code/cripts that deals with building the openscad appimage?
<ali1234>
.circleci/config.yaml?
<ali1234>
okay i read the scrollback, i think there is misunderstanding about what a venv actually is
<ali1234>
it's an overlay over the system python basically
<ali1234>
the system python is all the junk found in /usr/lib/python3.12
<ali1234>
a venv, by default, is empty, and inherits the standard library from the system environment
<ali1234>
that's which it is virtual. it is actually an overlay on something else, the "something else" being the thing you need to ship
<ali1234>
a venv is *only* necessary for installing extra libraries
<teepee>
yes, either empty list of installed packages (except pip) or you *can* inherit from system - at least that's what PyCharm offers
<teepee>
appimages are built via docker so the first steps are in the Dockerfile
<ali1234>
it always inherits the standard library and you can choose whether to inherit other system-wide packages
<teepee>
or the step in the .circlci/config.yaml which is building the offical download on CircleCI
<teepee>
if it always inherits the stdlib, how does that deal with vastely different python versions
<teepee>
is that handled in the standard lib?
<ali1234>
the venv contains a symlink to the python interpreter that matches the base system
<ali1234>
that's *how* the inheritance works
<ali1234>
the interpreter knows where its "real" system is
<ali1234>
if you change that symlink to a different python version, all the packages installed within the venv break
<ali1234>
well, the C ones do
<ali1234>
and any pyc files become invalid
<ali1234>
basically don't do this
<teepee>
right, so it's indirect via the interpreter, or in our case the setup in the init-code calling libpython
<ali1234>
right
<teepee>
guso78: the python init code seems to re-init before doing processing, but it also leaks imports to the next run
<teepee>
is that just due to the fact we did not merge everything yet?
<ali1234>
also if you install "programs" in a venv, then the executable scrpts placed in venv/bin are wrappers that automatically activate the venv and point to the right interpreter
<ali1234>
iow you can just directly run them without activating the venv and they magically set everything up
<teepee>
I suppose this will be the year of "learning more than you ever wanted about python" :-)
<gbruno>
[github] kintel closed pull request #5630 ([UX] Add of the "Jump to..." navigation method and clean the "Window" menu of its duplicated elements) https://github.com/openscad/openscad/pull/5630
<gbruno>
[github] kintel pushed 2 additions 8 modifications ([UX] Add of the "Jump to..." navigation method and clean the "Window" menu of its duplicated elements (#5630) * Add of the "Jump to..." navigation method and clean the "Window" menu of its duplicated elements * Add overlay hint to indicate to users the selected dock. * Move the title management on topLevelChanged from MainWindow into Dock. * Replace the dock title management in MainWindow & TabManager by th
stealth__ has joined #openscad
stealth_ has quit [Ping timeout: 252 seconds]
lastrodamo has quit [Quit: Leaving]
<guso78k>
teepee can you send me a link/artefact for re-init ?
<teepee>
we can check later, not critical, I just tried changing the "from openscad import *" to "from openscad import cube" and it did still have the show()
<guso78k>
Yeahh, as mentioned, many pip modules dont support re-init after de-init, so my strategy is not to deinit and clean up libs and variables. i can pr my solution next
<guso78k>
but i understand ,its a sensitive topic. openscad should stay a what-you-see-is-what-you get ...
<teepee>
not very urgent I guess
<teepee>
but if you have something, that's good
<guso78k>
:) i am happy that python finally found a way into openscad. I am most excited about designs, people will come up with the new features.
<guso78k>
even rebuyer010101 (from reddit) managed to use my functions in a way, which i did not consider, and it was absolutely cool)
<teepee>
uh, that python plugin compiles a fresh python
<guso78k>
yes, but it does a reliable job
<guso78k>
is it a timing issue in the ci cloud ?
<guso78k>
teepee, your link actually already shows the implementation of "undo initialization" I just need to PR my compete solution
<teepee>
first run of the plugin failed :(
<guso78k>
hmm did you update the "Desired" extact python version ? yes, you need to select one
guso78k has quit [Quit: Client closed]
guso78k has joined #openscad
<teepee>
no, but there's also something fishy with the extracted plugin
<teepee>
#10 63.27 cp: cannot stat '/appimage/usr/bin/share/python-wrapper.sh': No such file or directory
<teepee>
it did put the script somewhere else
<ali1234>
guso78k: for me the interesting part is you can much easier export multiple versions of a parametric design very easily
<ali1234>
rather than telling people to use the customizer, you can just offer them a choice of 3mf files to pick the one they want
<ali1234>
combining openscad with numpy will also be interesting
<ali1234>
it would be good to have polygon() support reading from a numpy array
<teepee>
is there a file format for that too?
<teepee>
guso78: which python version did you use with the linuxdeploy plugin?
<ali1234>
a file format?
<teepee>
is there a dedicated file format for numpy so we could have an scad import using that?
<ali1234>
no, numpy arrays are in-memory objects
<ali1234>
numpy is a vector math library for python
<teepee>
I know
<ali1234>
numpy arrays are just a python wrapper around C arrays
<teepee>
which would not exlude having a format for external storage too
<ali1234>
well arrays have tofile("filename") and fromfile()
<ali1234>
but these are just memory dumps
<ali1234>
in fact when you import you have to specify the C type and shape of the data
<ali1234>
i suppose you could implement that as a way to import an array but i don't think it would be very useful because you'd have to use a hexeditor to create the files