cfagley@codeus.tech Cody is a multilinguist programmer who has been coding/hacking from a young age. He grew up in a collection of small towns in Wyoming (e.g. Basin, Powell, and Sheridan). Cody holds a degree in Computer Science from University of Wyoming; since graduating he has focused his energy on building Codeus Tech and X-Ita Control System. He built Codeus Tech to extend his research in intrinsically-secure systems design.
+
Lisa Fagley
+
lisa.ann.fagley@gmail.com Lisa is also a Wyoming native and alumni of University of Wyoming (Finance). She has been a key asset in fine tuning Codeus Tech's financial plan. As primary financier of Codeus Tech, Lisa also helps Wells Fargo clientele make better long-term financial decisions.
+
Advisors
David Bohling
+
dbohlin1@uwyo.edu David Bohling (Dave) previously served as Principle Investigator on semiconductor research, funded by DARPA. His investigation was ultimately completed under-budget and faster than expected. Dave has a proven track record of successfully managing various technologies in concurrency.
+
Ed Hart
+
Codeus Tech is honored to be advised by Edward Hart, previous Deputy Director for Information Security of National Security Agency (NSA). While working with NSA, Ed oversaw development of some of the world's most advanced and secure IoT devices. In private industry, he has played a key role in several successful entities -- founding, managing and as a member of various boards.
+
Jerad Stack
+
Jerad Stack is a successful Founder/CEO and Wyoming business leader. Jerad has had a prolific career in engineering and simulation with Firehole Composites (later acquired by AutoDesk). He continues to use his expertise to help growing companies reach their next steps.
+
\ No newline at end of file
diff --git a/about/index.html b/about/index.html
new file mode 100644
index 0000000..0d368fa
--- /dev/null
+++ b/about/index.html
@@ -0,0 +1,11 @@
+Codeus Tech
cfagley@codeus.tech Cody is a multilinguist programmer who has been coding/hacking from a young age. He grew up in a collection of small towns in Wyoming (e.g. Basin, Powell, and Sheridan). Cody holds a degree in Computer Science from University of Wyoming; since graduating he has focused his energy on building Codeus Tech and X-Ita Control System. He built Codeus Tech to extend his research in intrinsically-secure systems design.
+
Lisa Fagley
+
lisa.ann.fagley@gmail.com Lisa is also a Wyoming native and alumni of University of Wyoming (Finance). She has been a key asset in fine tuning Codeus Tech's financial plan. As primary financier of Codeus Tech, Lisa also helps Wells Fargo clientele make better long-term financial decisions.
+
Advisors
David Bohling
+
dbohlin1@uwyo.edu David Bohling (Dave) previously served as Principle Investigator on semiconductor research, funded by DARPA. His investigation was ultimately completed under-budget and faster than expected. Dave has a proven track record of successfully managing various technologies in concurrency.
+
Ed Hart
+
Codeus Tech is honored to be advised by Edward Hart, previous Deputy Director for Information Security of National Security Agency (NSA). While working with NSA, Ed oversaw development of some of the world's most advanced and secure IoT devices. In private industry, he has played a key role in several successful entities -- founding, managing and as a member of various boards.
+
Jerad Stack
+
Jerad Stack is a successful Founder/CEO and Wyoming business leader. Jerad has had a prolific career in engineering and simulation with Firehole Composites (later acquired by AutoDesk). He continues to use his expertise to help growing companies reach their next steps.
+
\ No newline at end of file
diff --git a/blog/2019/01/07/startups-across-the-state.html b/blog/2019/01/07/startups-across-the-state.html
new file mode 100644
index 0000000..7aa4d08
--- /dev/null
+++ b/blog/2019/01/07/startups-across-the-state.html
@@ -0,0 +1,93 @@
+Startups Across the State · Codeus Tech
Recent alumnus Cody Fagley wants to change the world—the world of computers, that is, where most Americans spend the majority of their workdays. His foundational cybersecurity company, Codeus Tech, is currently incubated in the University of Wyoming’s Wyoming Technology Business Center (WTBC) on the UW campus.
+
However, the university doesn’t just help Laramie entrepreneurs. Affiliated programs work with businesses and potential businesses across the state, such as Aerial Enforcement Solutions in Casper, a startup company that will produce drone platforms for use by law enforcement and firefighting; and Old Army Records in Sheridan, a startup that compiles and disseminates information on a full range of 19th century U.S. military topics.
+
Codeus Tech
+
“I wanted to perform cutting-edge research within cybersecurity. I looked at the computing greats, and I wanted to follow in their footsteps,” says Fagley, who graduated with his degree in computer science in December 2017. “We’re looking at trying to solve software holes near the hardware level. We have a flagship product that’s enormous. It includes a programming language, and a lot of what people traditionally know as an operating system exists within that programming language.”
+
How could this change the world? “In our perfect world, long term, we won’t have any Windows or Linux computers anymore. We’ll replace them outright. We won’t have dynamic random-access memory in our computers. That’s our long-term goal,” says Fagley, who grew up in Basin and went to high school in Powell.
+
WTBC Director David Bohling has helped Fagley at every step. “Codeus is carving out an entirely new way to approach operating systems and security—the security being the original catalyst for the concept,” Bohling says.
+
Fagley says, “They’ve helped us find opportunities, expand on our strengths, analyze our weaknesses, analyze viability within the market—any aspect of running a company. Nothing that we’re doing right now is possible without the WTBC.”
+
He also gives credit to computer science Professor Ruben Gamboa, who sent him to a conference that helped inspire Codeus. The company currently employs a handful of people but is seeking government grants to grow. Fagley—who also participated in UW’s $30K Ellbogen Entrepreneurship Competition, now the John P. Ellbogen $50K Entrepreneurship Competition—wants to keep Codeus in Wyoming and contribute to the state’s economy. He loves the outdoor lifestyle here.
+
“I want to thank UW for providing programs like the WTBC, the Small Business Development Center Network—all of them,” Fagley says. “For us, it’s life changing.”
+a woman and a man standing beside a business sign
+Nicol and Todd Kramer received seed funds for their company, Aerial Enforcement Solutions, from the Casper Start-Up Challenge. (Photo Courtesy of WTBC)
+
Aerial Enforcement Solutions
+
In Casper, Nicol Kramer was driving her kids to school one day when she heard about the WTBC’s 2017 Casper Start-Up Challenge. Her husband, Todd, had been tinkering with a company idea for a while, but financing it from their own budget was limiting. That night, after the kids went to bed, they entered the contest and went on to become finalists.
+
“I work for a company that sells law enforcement products for riot control,” Todd says. “Being a drone enthusiast, I married the two ideas. Our company will produce and manufacturer drone platforms for use by law enforcement and firefighting. With the feedback we’ve gotten from law enforcement, it looks to be a really good solution for riot control.”
+
Aerial Enforcement Solutions won seed money and is now incubated in the WTBC Casper-Area Incubator. “It’s been a great resource,” Todd says. He notes great feedback from business leaders and information from the Wyoming Technology Transfer and Research Products Center that helped them seek a more rigid patent.
+
Their AirGhost product fits in well with tremendous growth of drone use by law enforcement, and AirGhost also has potential for use in firefighting, the military and pest control.
+
Nicol encourages other entrepreneurs to enter WTBC startup challenges (see sidebar). “Even if you don’t get into the final three, the whole process is beneficial,” she says. “You work with the staff at the WTBC to vet your idea. They’ve worked with a lot of businesses and technologies, so they can offer advice on resources, ideas on how to focus on your market and the typical roll-out of a business. It definitely helps you focus on the business and get it moving.”
+two men standing in front of a video display
+Jim Powers and Kevin O’Dell started Old Army Records with help from the Sheridan-Area Incubator Start-Up Challenge. (Photo by Gini Horner)
+
Old Army Records
+
In 1992, Kevin O’Dell, a college student from Sheridan, and Jim Powers, a former aviation mechanic from Chicago, met at an archaeological dig at Fort Phil Kearny State Historic Site near Banner and discovered a shared passion for history—especially 19th century U.S. military history. Their friendship and work continued, and in 2004 an idea for a business formed when they were working on an archaeological survey of the Fetterman Battlefield and were in need of accurate primary documentation to be able to place the artifacts they were finding in the correct historical context. Internet information was sparse and sometimes contradictory, forcing them to seek out original government documents from sources including the National Archives in Washington, D.C.
+
Thus, the idea for Old Army Records LLC was born. “Our vision is to bring the lives of the old Army soldiers to light and in the process bring us all closer to our collective roots,” Powers says. “Our website will be the vehicle to facilitate the distribution of that information by allowing access, for a fee, to our extensive and comprehensive database of original old Army records obtained from various archives and collections, such as the National Archives and Library of Congress.”
+
Old Army Records is a niche business designed to augment the general data presented by the large genealogy websites. “It is presented to those who are searching for more than the bare statistics on a person,” Powers says. “It will provide the details of a soldier’s life, including crime and punishment, promotions and demotions, medical and casualty data, daily activities and participation in engagements. The information allows the student, genealogist or serious researcher to understand the day-to-day life of an old Army soldier.”
+
Their business was one of the winners of the 2017 WTBC Sheridan-Area Incubator Start-Up Challenge. “The level of expertise and support that was provided by the staff, sponsors and judges was both helpful and enlightening,” Powers says. “Even though Kevin and I had both owned and operated businesses before, we had not been involved with a web-based one before and were overwhelmed with the details in starting one from scratch. Luckily, many of the judges had experiences with them, and they were glad to impart their knowledge.”
+
As a result of the challenge, they received seed money, legal and business services, and incubator office space. Powers says, “As a result, last fall we launched our website, oldarmyrecords.com, and advanced our database development.”
+
They currently update the website biweekly with articles on a variety of old Army subjects taken from records in their collection. The subscription database application, offering a dataset of about 14,000 general court martial cases, will come online in early 2019.
+
The Wyoming Technology Business Center
+
The WTBC is part of the University of Wyoming’s mission to provide education and support to business startups throughout the state. Facilities in Laramie, Casper and Sheridan offer lab, office and conference room space for clients, and clients also receive counseling to help their companies grow larger and faster than they would otherwise. In addition, a statewide networking group, e2e, works to improve the startup climate in Wyoming.
+
“Our job is to spur economic development in any way we can,” says WTBC Director David Bohling. This includes directing entrepreneurs to all the services of the Business Resource Network (uwyo.edu/research/business-resource-network) and, soon, the newly launched Institute of Innovation and Entrepreneurship
+
“We try to bring high-level mentoring to our clients, whoever they are and wherever they come from,” Bohling says.
+
Each WTBC incubator hosts a startup challenge. The Casper Start-Up Challenge and Sheridan Start-Up Challenge each provide a $50,000 seed fund incentive as well as business support. Finalists work closely with WTBC staff to develop their business ideas. All finalists gain business process knowledge as they progress through the phases of competition, regardless of the competition outcome. The top three finalists each receive $5,000 and are eligible to access the $50,000 seed fund.
+
The Fisher Innovation Launchpad (previously the Fisher Innovation Challenge) in Laramie is supported through the generous financial gift of Donne Fisher and matched by the UW Office of Research and Economic Development. It seeks to catalyze Wyoming technology startup businesses and provide the opportunity for them to apply for seed money to take the business past concept stage and into real-world first-article builds and initial sales. The competition identifies finalists who are eligible to pitch for the chance to apply to the $125,000 seed fund. All teams must each include a UW student, graduate student or post-doc.
+
Before the Fisher fund, Laramie had 40 to 50 tech companies establish organically, Bohling says. “In the last three years with Fisher, we’ve generated 22 more,” he says, adding that Casper has already generated eight new businesses with its challenge and Sheridan three.
+
The challenges spur business ideas that entrepreneurs wouldn’t have pursued otherwise. “Our statistics show that roughly 80 percent of students who enter wouldn’t have done it without the challenge,” Bohling says. “They come talk to us, and we do an ideation session to brainstorm. With that, you can generate a business if you have the energy.”
\ No newline at end of file
diff --git a/blog/2019/01/07/startups-across-the-state/index.html b/blog/2019/01/07/startups-across-the-state/index.html
new file mode 100644
index 0000000..7aa4d08
--- /dev/null
+++ b/blog/2019/01/07/startups-across-the-state/index.html
@@ -0,0 +1,93 @@
+Startups Across the State · Codeus Tech
Recent alumnus Cody Fagley wants to change the world—the world of computers, that is, where most Americans spend the majority of their workdays. His foundational cybersecurity company, Codeus Tech, is currently incubated in the University of Wyoming’s Wyoming Technology Business Center (WTBC) on the UW campus.
+
However, the university doesn’t just help Laramie entrepreneurs. Affiliated programs work with businesses and potential businesses across the state, such as Aerial Enforcement Solutions in Casper, a startup company that will produce drone platforms for use by law enforcement and firefighting; and Old Army Records in Sheridan, a startup that compiles and disseminates information on a full range of 19th century U.S. military topics.
+
Codeus Tech
+
“I wanted to perform cutting-edge research within cybersecurity. I looked at the computing greats, and I wanted to follow in their footsteps,” says Fagley, who graduated with his degree in computer science in December 2017. “We’re looking at trying to solve software holes near the hardware level. We have a flagship product that’s enormous. It includes a programming language, and a lot of what people traditionally know as an operating system exists within that programming language.”
+
How could this change the world? “In our perfect world, long term, we won’t have any Windows or Linux computers anymore. We’ll replace them outright. We won’t have dynamic random-access memory in our computers. That’s our long-term goal,” says Fagley, who grew up in Basin and went to high school in Powell.
+
WTBC Director David Bohling has helped Fagley at every step. “Codeus is carving out an entirely new way to approach operating systems and security—the security being the original catalyst for the concept,” Bohling says.
+
Fagley says, “They’ve helped us find opportunities, expand on our strengths, analyze our weaknesses, analyze viability within the market—any aspect of running a company. Nothing that we’re doing right now is possible without the WTBC.”
+
He also gives credit to computer science Professor Ruben Gamboa, who sent him to a conference that helped inspire Codeus. The company currently employs a handful of people but is seeking government grants to grow. Fagley—who also participated in UW’s $30K Ellbogen Entrepreneurship Competition, now the John P. Ellbogen $50K Entrepreneurship Competition—wants to keep Codeus in Wyoming and contribute to the state’s economy. He loves the outdoor lifestyle here.
+
“I want to thank UW for providing programs like the WTBC, the Small Business Development Center Network—all of them,” Fagley says. “For us, it’s life changing.”
+a woman and a man standing beside a business sign
+Nicol and Todd Kramer received seed funds for their company, Aerial Enforcement Solutions, from the Casper Start-Up Challenge. (Photo Courtesy of WTBC)
+
Aerial Enforcement Solutions
+
In Casper, Nicol Kramer was driving her kids to school one day when she heard about the WTBC’s 2017 Casper Start-Up Challenge. Her husband, Todd, had been tinkering with a company idea for a while, but financing it from their own budget was limiting. That night, after the kids went to bed, they entered the contest and went on to become finalists.
+
“I work for a company that sells law enforcement products for riot control,” Todd says. “Being a drone enthusiast, I married the two ideas. Our company will produce and manufacturer drone platforms for use by law enforcement and firefighting. With the feedback we’ve gotten from law enforcement, it looks to be a really good solution for riot control.”
+
Aerial Enforcement Solutions won seed money and is now incubated in the WTBC Casper-Area Incubator. “It’s been a great resource,” Todd says. He notes great feedback from business leaders and information from the Wyoming Technology Transfer and Research Products Center that helped them seek a more rigid patent.
+
Their AirGhost product fits in well with tremendous growth of drone use by law enforcement, and AirGhost also has potential for use in firefighting, the military and pest control.
+
Nicol encourages other entrepreneurs to enter WTBC startup challenges (see sidebar). “Even if you don’t get into the final three, the whole process is beneficial,” she says. “You work with the staff at the WTBC to vet your idea. They’ve worked with a lot of businesses and technologies, so they can offer advice on resources, ideas on how to focus on your market and the typical roll-out of a business. It definitely helps you focus on the business and get it moving.”
+two men standing in front of a video display
+Jim Powers and Kevin O’Dell started Old Army Records with help from the Sheridan-Area Incubator Start-Up Challenge. (Photo by Gini Horner)
+
Old Army Records
+
In 1992, Kevin O’Dell, a college student from Sheridan, and Jim Powers, a former aviation mechanic from Chicago, met at an archaeological dig at Fort Phil Kearny State Historic Site near Banner and discovered a shared passion for history—especially 19th century U.S. military history. Their friendship and work continued, and in 2004 an idea for a business formed when they were working on an archaeological survey of the Fetterman Battlefield and were in need of accurate primary documentation to be able to place the artifacts they were finding in the correct historical context. Internet information was sparse and sometimes contradictory, forcing them to seek out original government documents from sources including the National Archives in Washington, D.C.
+
Thus, the idea for Old Army Records LLC was born. “Our vision is to bring the lives of the old Army soldiers to light and in the process bring us all closer to our collective roots,” Powers says. “Our website will be the vehicle to facilitate the distribution of that information by allowing access, for a fee, to our extensive and comprehensive database of original old Army records obtained from various archives and collections, such as the National Archives and Library of Congress.”
+
Old Army Records is a niche business designed to augment the general data presented by the large genealogy websites. “It is presented to those who are searching for more than the bare statistics on a person,” Powers says. “It will provide the details of a soldier’s life, including crime and punishment, promotions and demotions, medical and casualty data, daily activities and participation in engagements. The information allows the student, genealogist or serious researcher to understand the day-to-day life of an old Army soldier.”
+
Their business was one of the winners of the 2017 WTBC Sheridan-Area Incubator Start-Up Challenge. “The level of expertise and support that was provided by the staff, sponsors and judges was both helpful and enlightening,” Powers says. “Even though Kevin and I had both owned and operated businesses before, we had not been involved with a web-based one before and were overwhelmed with the details in starting one from scratch. Luckily, many of the judges had experiences with them, and they were glad to impart their knowledge.”
+
As a result of the challenge, they received seed money, legal and business services, and incubator office space. Powers says, “As a result, last fall we launched our website, oldarmyrecords.com, and advanced our database development.”
+
They currently update the website biweekly with articles on a variety of old Army subjects taken from records in their collection. The subscription database application, offering a dataset of about 14,000 general court martial cases, will come online in early 2019.
+
The Wyoming Technology Business Center
+
The WTBC is part of the University of Wyoming’s mission to provide education and support to business startups throughout the state. Facilities in Laramie, Casper and Sheridan offer lab, office and conference room space for clients, and clients also receive counseling to help their companies grow larger and faster than they would otherwise. In addition, a statewide networking group, e2e, works to improve the startup climate in Wyoming.
+
“Our job is to spur economic development in any way we can,” says WTBC Director David Bohling. This includes directing entrepreneurs to all the services of the Business Resource Network (uwyo.edu/research/business-resource-network) and, soon, the newly launched Institute of Innovation and Entrepreneurship
+
“We try to bring high-level mentoring to our clients, whoever they are and wherever they come from,” Bohling says.
+
Each WTBC incubator hosts a startup challenge. The Casper Start-Up Challenge and Sheridan Start-Up Challenge each provide a $50,000 seed fund incentive as well as business support. Finalists work closely with WTBC staff to develop their business ideas. All finalists gain business process knowledge as they progress through the phases of competition, regardless of the competition outcome. The top three finalists each receive $5,000 and are eligible to access the $50,000 seed fund.
+
The Fisher Innovation Launchpad (previously the Fisher Innovation Challenge) in Laramie is supported through the generous financial gift of Donne Fisher and matched by the UW Office of Research and Economic Development. It seeks to catalyze Wyoming technology startup businesses and provide the opportunity for them to apply for seed money to take the business past concept stage and into real-world first-article builds and initial sales. The competition identifies finalists who are eligible to pitch for the chance to apply to the $125,000 seed fund. All teams must each include a UW student, graduate student or post-doc.
+
Before the Fisher fund, Laramie had 40 to 50 tech companies establish organically, Bohling says. “In the last three years with Fisher, we’ve generated 22 more,” he says, adding that Casper has already generated eight new businesses with its challenge and Sheridan three.
+
The challenges spur business ideas that entrepreneurs wouldn’t have pursued otherwise. “Our statistics show that roughly 80 percent of students who enter wouldn’t have done it without the challenge,” Bohling says. “They come talk to us, and we do an ideation session to brainstorm. With that, you can generate a business if you have the energy.”
\ No newline at end of file
diff --git a/blog/2019/11/29/codeus-named-sewyil-finalist.html b/blog/2019/11/29/codeus-named-sewyil-finalist.html
new file mode 100644
index 0000000..39aae98
--- /dev/null
+++ b/blog/2019/11/29/codeus-named-sewyil-finalist.html
@@ -0,0 +1,61 @@
+Codeus named SEWYIL finalist · Codeus Tech
Codeus Tech has been chosen as a finalist in Wyoming's first annual Southeastern Wyoming Innovation Launchpad. As part of this event, Cody Fagley will be giving a presentation, on the X-Ita Control System (XCS), in Cheyenne this upcoming January.
\ No newline at end of file
diff --git a/blog/2019/11/29/codeus-named-sewyil-finalist/index.html b/blog/2019/11/29/codeus-named-sewyil-finalist/index.html
new file mode 100644
index 0000000..39aae98
--- /dev/null
+++ b/blog/2019/11/29/codeus-named-sewyil-finalist/index.html
@@ -0,0 +1,61 @@
+Codeus named SEWYIL finalist · Codeus Tech
Codeus Tech has been chosen as a finalist in Wyoming's first annual Southeastern Wyoming Innovation Launchpad. As part of this event, Cody Fagley will be giving a presentation, on the X-Ita Control System (XCS), in Cheyenne this upcoming January.
Optimization Modes are backend configurations to be used for situational performance gains. Developers do not need to know much about these settings other than which is best for their specific application.
+
Modes
+
a64 (Default)
+
a64 is the default optimization mode in XCS, because it has no constraints or other information to know. It is suitable for any 32/64-bit application.
+
a32i
+
a32i is the fastest optimization mode but has constraints:
\ No newline at end of file
diff --git a/docs/xcs/xcs-config/index.html b/docs/xcs/xcs-config/index.html
new file mode 100644
index 0000000..9ad124d
--- /dev/null
+++ b/docs/xcs/xcs-config/index.html
@@ -0,0 +1,77 @@
+Optimization Schemes · Codeus Tech
Optimization Modes are backend configurations to be used for situational performance gains. Developers do not need to know much about these settings other than which is best for their specific application.
+
Modes
+
a64 (Default)
+
a64 is the default optimization mode in XCS, because it has no constraints or other information to know. It is suitable for any 32/64-bit application.
+
a32i
+
a32i is the fastest optimization mode but has constraints:
\ No newline at end of file
diff --git a/docs/xcs/xcs-install.html b/docs/xcs/xcs-install.html
new file mode 100644
index 0000000..2c565e6
--- /dev/null
+++ b/docs/xcs/xcs-install.html
@@ -0,0 +1,73 @@
+Installation · Codeus Tech
\ No newline at end of file
diff --git a/docs/xcs/xcs-install/index.html b/docs/xcs/xcs-install/index.html
new file mode 100644
index 0000000..2c565e6
--- /dev/null
+++ b/docs/xcs/xcs-install/index.html
@@ -0,0 +1,73 @@
+Installation · Codeus Tech
\ No newline at end of file
diff --git a/docs/xcs/xcs-shell.html b/docs/xcs/xcs-shell.html
new file mode 100644
index 0000000..e88bd5b
--- /dev/null
+++ b/docs/xcs/xcs-shell.html
@@ -0,0 +1,77 @@
+Shell Commands · Codeus Tech
The XCS shell provides quick and easy frontend access to several system modules. When operating within the shell, it is not necessary to make requests to system functions. Instead, you can call the service function directly, and the shell will make the request automatically.
+
Tether Modules that are automatically activated upon startup include:
+
+
Firmware Drivers
+
Network Sockets
+
+
+
Hotkeys
+
Clipboard Usage
+
+
ctrl+shift + c: Copy highlighted text to clipboard
+
ctrl+shift + v: Paste text to shell from clipboard
\ No newline at end of file
diff --git a/docs/xcs/xcs-shell/index.html b/docs/xcs/xcs-shell/index.html
new file mode 100644
index 0000000..e88bd5b
--- /dev/null
+++ b/docs/xcs/xcs-shell/index.html
@@ -0,0 +1,77 @@
+Shell Commands · Codeus Tech
The XCS shell provides quick and easy frontend access to several system modules. When operating within the shell, it is not necessary to make requests to system functions. Instead, you can call the service function directly, and the shell will make the request automatically.
+
Tether Modules that are automatically activated upon startup include:
+
+
Firmware Drivers
+
Network Sockets
+
+
+
Hotkeys
+
Clipboard Usage
+
+
ctrl+shift + c: Copy highlighted text to clipboard
+
ctrl+shift + v: Paste text to shell from clipboard
\ No newline at end of file
diff --git a/docs/xcs/xcs.html b/docs/xcs/xcs.html
new file mode 100644
index 0000000..876786f
--- /dev/null
+++ b/docs/xcs/xcs.html
@@ -0,0 +1,67 @@
+X-Ita Control System · Codeus Tech
Here, you can find information useful for development of X-Ita Control System Language (XCSL) -- specifically targeting 64-bit ARM architecture. For documentation and usage information, please see below:
\ No newline at end of file
diff --git a/docs/xcs/xcs/index.html b/docs/xcs/xcs/index.html
new file mode 100644
index 0000000..876786f
--- /dev/null
+++ b/docs/xcs/xcs/index.html
@@ -0,0 +1,67 @@
+X-Ita Control System · Codeus Tech
Here, you can find information useful for development of X-Ita Control System Language (XCSL) -- specifically targeting 64-bit ARM architecture. For documentation and usage information, please see below:
\ No newline at end of file
diff --git a/docs/xcse/xcse-ffi.html b/docs/xcse/xcse-ffi.html
new file mode 100644
index 0000000..b95df97
--- /dev/null
+++ b/docs/xcse/xcse-ffi.html
@@ -0,0 +1,62 @@
+Foreign Function Interface · Codeus Tech
Foreign Function Interfaces (FFI) translate source code between XCSL and other functional programming languages. FFI is one of the most core subsystems within XCS; even XCSL itself is defined within FFI.
+
FFI is used to define syntax recognition for other programming languages (e.g. Haskell, Caml, LISP). This module can also be used to build new languages/programs.
\ No newline at end of file
diff --git a/docs/xcse/xcse-ffi/index.html b/docs/xcse/xcse-ffi/index.html
new file mode 100644
index 0000000..b95df97
--- /dev/null
+++ b/docs/xcse/xcse-ffi/index.html
@@ -0,0 +1,62 @@
+Foreign Function Interface · Codeus Tech
Foreign Function Interfaces (FFI) translate source code between XCSL and other functional programming languages. FFI is one of the most core subsystems within XCS; even XCSL itself is defined within FFI.
+
FFI is used to define syntax recognition for other programming languages (e.g. Haskell, Caml, LISP). This module can also be used to build new languages/programs.
\ No newline at end of file
diff --git a/docs/xcse/xcse-firmware.html b/docs/xcse/xcse-firmware.html
new file mode 100644
index 0000000..aa6c7b6
--- /dev/null
+++ b/docs/xcse/xcse-firmware.html
@@ -0,0 +1,121 @@
+Firmware Interface · Codeus Tech
XCS provides a standard Serial Peripheral Interface (SPI) interface library for developing custom SPI devices/firmware. Only one SPI driver can be activated at once per device.
+
Import SPI Interface
+
open System "SPI"
+
+
SPI Pin Settings
+
request spi_cs_high -- Sets CS pin to 'High' setting
+request spi_cs_low -- Sets CS pin to 'Low' setting
+
+
Read Data from SPI
+
-- Returns u32 value from connected SPI device
+request spi_read -- Retrieves next entry after read
+request spi_peek -- Leaves entry after read
+
+
Write Data to SPI
+
-- Returns/Writes u32 value to connected SPI device
+request spi_write x
+
+
Using SPI Driver
+
Once a driver is written for an SPI device, it can be enabled in the XCS shell with the following command:
+
-- Note: the file MUST point to a Tether Module
+file spi_driver = "driver-file-name"
+activateSPI spi_driver
+
+
I2C
+
XCS provides a standard Inter-Integrated Circuits (I2C) interface library for developing custom I2C devices/firmware. Only one I2C driver can be activated at once per device.
+
Import I2C Interface
+
open System "I2C"
+
+
Read Data from I2C
+
-- Returns u32 value from connected I2C device
+request i2c_read -- Retrieves next entry after read
+request i2c_peek -- Reads entry without retreiving next entry after read
+
+
Write Data to I2C
+
-- Returns/Writes u32 value to connected I2C device
+request i2c_write x
+
+
Using I2C Driver
+
Once a driver is written for an I2C device, it can be enabled in the XCS shell with the following command:
+
-- Note: the file MUST point to a Tether Module
+file i2c_driver = "driver-file-name"
+activateI2C i2c_driver
+
+
UART
+
XCS provides a standard Serial Peripheral Interface (UART) interface library for developing custom UART devices/firmware. Only one UART driver can be activated at once per device.
+
Import UART Interface
+
open System "UART"
+
+
Read Data from UART
+
-- Returns u32 value from connected UART device
+request uart_read -- Retrieves next entry after read
+request uart_peek -- Leaves entry after read
+
+
Write Data to UART
+
-- Returns/Writes u32 value to connected UART device
+request uart_write x
+
+
Using UART Driver
+
Once a driver is written for an UART device, it can be enabled in the XCS shell with the following command:
+
-- Note: the file MUST point to a Tether Module
+file uart_driver = "driver-file-name"
+activateUART uart_driver
+
\ No newline at end of file
diff --git a/docs/xcse/xcse-firmware/index.html b/docs/xcse/xcse-firmware/index.html
new file mode 100644
index 0000000..aa6c7b6
--- /dev/null
+++ b/docs/xcse/xcse-firmware/index.html
@@ -0,0 +1,121 @@
+Firmware Interface · Codeus Tech
XCS provides a standard Serial Peripheral Interface (SPI) interface library for developing custom SPI devices/firmware. Only one SPI driver can be activated at once per device.
+
Import SPI Interface
+
open System "SPI"
+
+
SPI Pin Settings
+
request spi_cs_high -- Sets CS pin to 'High' setting
+request spi_cs_low -- Sets CS pin to 'Low' setting
+
+
Read Data from SPI
+
-- Returns u32 value from connected SPI device
+request spi_read -- Retrieves next entry after read
+request spi_peek -- Leaves entry after read
+
+
Write Data to SPI
+
-- Returns/Writes u32 value to connected SPI device
+request spi_write x
+
+
Using SPI Driver
+
Once a driver is written for an SPI device, it can be enabled in the XCS shell with the following command:
+
-- Note: the file MUST point to a Tether Module
+file spi_driver = "driver-file-name"
+activateSPI spi_driver
+
+
I2C
+
XCS provides a standard Inter-Integrated Circuits (I2C) interface library for developing custom I2C devices/firmware. Only one I2C driver can be activated at once per device.
+
Import I2C Interface
+
open System "I2C"
+
+
Read Data from I2C
+
-- Returns u32 value from connected I2C device
+request i2c_read -- Retrieves next entry after read
+request i2c_peek -- Reads entry without retreiving next entry after read
+
+
Write Data to I2C
+
-- Returns/Writes u32 value to connected I2C device
+request i2c_write x
+
+
Using I2C Driver
+
Once a driver is written for an I2C device, it can be enabled in the XCS shell with the following command:
+
-- Note: the file MUST point to a Tether Module
+file i2c_driver = "driver-file-name"
+activateI2C i2c_driver
+
+
UART
+
XCS provides a standard Serial Peripheral Interface (UART) interface library for developing custom UART devices/firmware. Only one UART driver can be activated at once per device.
+
Import UART Interface
+
open System "UART"
+
+
Read Data from UART
+
-- Returns u32 value from connected UART device
+request uart_read -- Retrieves next entry after read
+request uart_peek -- Leaves entry after read
+
+
Write Data to UART
+
-- Returns/Writes u32 value to connected UART device
+request uart_write x
+
+
Using UART Driver
+
Once a driver is written for an UART device, it can be enabled in the XCS shell with the following command:
+
-- Note: the file MUST point to a Tether Module
+file uart_driver = "driver-file-name"
+activateUART uart_driver
+
\ No newline at end of file
diff --git a/docs/xcse/xcse-modules.html b/docs/xcse/xcse-modules.html
new file mode 100644
index 0000000..30b3308
--- /dev/null
+++ b/docs/xcse/xcse-modules.html
@@ -0,0 +1,99 @@
+Module Types · Codeus Tech
Source Modules are XCSL files that are meant to be executed as program (source) code. In source modules, all XCSL code outside of function declarations is treated as executable program code.
+
For example, see the following XCSL code:
+
let sum xy = x + y;;
+ sum 12
+
+
A source module would declare function sum, along with its proposed behavior, into the module tree. Then it would execute ( sum 1 2 ) and ultimately, return 3 to the shell.
+
+
Header Modules
+
Header Modules (aka Submodules) are organizational files containing loadable XCSL functions. They differ from Source Modules, as none of the code outside of function declarations is ever executed.
+
Recall the previous example module:
+
let sum xy = x + y;;
+ sum 12
+
+
While a source module would execute ( sum 1 2 ), a submodule would not. It would only declare the sum function for other modules' use.
+
+
Tether Modules
+
Tether Modules are relatively complicated to the aforementioned module types. They are best described as software-level protocols. They are not constantly-running active applications; rather, they offer services that can be requested by other modules. This maintains a reasonable barrier between user applications and firmware backends.
+
Tether modules must be activated for their services to be used. When done with a tether module, it is best practice to deactivate the module. See following example, where the file is named "TMod.xt":
+
activate TMod
+
+ deactivate TMod
+
+
Within TMod (and all other tether modules), functions can be offered to other modules.
+
offer diff xy = x - y
+
+
Then other modules could use the following request to use the diff function.
+
request TMod diff 21
+
+
This request would call TMod, then TMod would calculate the difference and return the result.
+
Though this may seem esoteric in the given examples, tether modules play a huge role in XCS multithreading.
+
+
System Modules
+
System Modules do not exist as source code within XCS; instead, they come defined within the ISO image used by the bootloader. They can be called using the following format:
+
request System FUNCTION
+
+
Where FUNCTION is some functionality within a System Module. These modules are typically ones that are required for XCSL to operate normally, e.g. memory allocator, process scheduler. Below find one of the most useful system functions:
\ No newline at end of file
diff --git a/docs/xcse/xcse-modules/index.html b/docs/xcse/xcse-modules/index.html
new file mode 100644
index 0000000..30b3308
--- /dev/null
+++ b/docs/xcse/xcse-modules/index.html
@@ -0,0 +1,99 @@
+Module Types · Codeus Tech
Source Modules are XCSL files that are meant to be executed as program (source) code. In source modules, all XCSL code outside of function declarations is treated as executable program code.
+
For example, see the following XCSL code:
+
let sum xy = x + y;;
+ sum 12
+
+
A source module would declare function sum, along with its proposed behavior, into the module tree. Then it would execute ( sum 1 2 ) and ultimately, return 3 to the shell.
+
+
Header Modules
+
Header Modules (aka Submodules) are organizational files containing loadable XCSL functions. They differ from Source Modules, as none of the code outside of function declarations is ever executed.
+
Recall the previous example module:
+
let sum xy = x + y;;
+ sum 12
+
+
While a source module would execute ( sum 1 2 ), a submodule would not. It would only declare the sum function for other modules' use.
+
+
Tether Modules
+
Tether Modules are relatively complicated to the aforementioned module types. They are best described as software-level protocols. They are not constantly-running active applications; rather, they offer services that can be requested by other modules. This maintains a reasonable barrier between user applications and firmware backends.
+
Tether modules must be activated for their services to be used. When done with a tether module, it is best practice to deactivate the module. See following example, where the file is named "TMod.xt":
+
activate TMod
+
+ deactivate TMod
+
+
Within TMod (and all other tether modules), functions can be offered to other modules.
+
offer diff xy = x - y
+
+
Then other modules could use the following request to use the diff function.
+
request TMod diff 21
+
+
This request would call TMod, then TMod would calculate the difference and return the result.
+
Though this may seem esoteric in the given examples, tether modules play a huge role in XCS multithreading.
+
+
System Modules
+
System Modules do not exist as source code within XCS; instead, they come defined within the ISO image used by the bootloader. They can be called using the following format:
+
request System FUNCTION
+
+
Where FUNCTION is some functionality within a System Module. These modules are typically ones that are required for XCSL to operate normally, e.g. memory allocator, process scheduler. Below find one of the most useful system functions:
\ No newline at end of file
diff --git a/docs/xcse/xcse-sockets.html b/docs/xcse/xcse-sockets.html
new file mode 100644
index 0000000..99421d9
--- /dev/null
+++ b/docs/xcse/xcse-sockets.html
@@ -0,0 +1,96 @@
+Network Sockets · Codeus Tech
XCS provides a built-in tether module, known as Socket for handling network communication. Socket is an XCSE-native tether module that provides low-level networking protocols, e.g. Ethernet Drivers, Internet Protocol (IP) Addresses.
+
Sockets are essentially a user interface for internet/networking within modules. Sockets allow your computer to talk to the local area network's router through Ports.
+
Socket provides these commands for accessing ports:
+
+
open PORT PROTOCOL
+
close PORT
+
read PORT
+
write PORT DATA
+
+
See sections below for example uses.
+
+
UDP Sockets
+
XCS provides sockets for User Datagram Protocol (UDP) communication. UDP is very fast, but operates with roughly 30% data loss. It is best practice to use UDP sockets when several packets are sent in a short period, and each packet is not particularly important.
+
See the following code example, which opens a UDP socket on port 80:
+
request socket_open 80UDP
+
+
After the socket has been opened, any other function within the module can use the following commands to write/read data to/from the socket:
+
request socket_write 80 data
+ request socket_read 80
+
+
When a socket is no longer needed (or the module has concluded), the socket must be closed by the program. This can be done like so:
+
request socket_close 80
+
+
+
TCP/IP Sockets
+
XCS provides Transmission Control Protocol (TCP) sockets for high-reliability networked communication. Unlike UDP, TCP will detect if a packet does not go through correctly and will resend the packet. So every TCP packet that is sent will be received by the client otherwise they are resent.
+
Although resending the packet ensures the information is delivered, it has a profound impact on efficiency and security. Flooding TCP sockets is a popular Dedicated Denial-of-Service (DDoS) strategy, so developers must detect/route attacks. Infrastructural mitigation is planned but not yet developed.
+
To open a socket for TCP on port 80:
+
request socket_open 80TCP
+
+
Once the socket is opened, data can be written/read exactly as it is in the UDP example. See below:
+
request socket_write 80 data
+ request socket_read 80
+
+
As with any other type of socket, make sure to close it at the end, so the network manager knows it is inactive.
\ No newline at end of file
diff --git a/docs/xcse/xcse-sockets/index.html b/docs/xcse/xcse-sockets/index.html
new file mode 100644
index 0000000..99421d9
--- /dev/null
+++ b/docs/xcse/xcse-sockets/index.html
@@ -0,0 +1,96 @@
+Network Sockets · Codeus Tech
XCS provides a built-in tether module, known as Socket for handling network communication. Socket is an XCSE-native tether module that provides low-level networking protocols, e.g. Ethernet Drivers, Internet Protocol (IP) Addresses.
+
Sockets are essentially a user interface for internet/networking within modules. Sockets allow your computer to talk to the local area network's router through Ports.
+
Socket provides these commands for accessing ports:
+
+
open PORT PROTOCOL
+
close PORT
+
read PORT
+
write PORT DATA
+
+
See sections below for example uses.
+
+
UDP Sockets
+
XCS provides sockets for User Datagram Protocol (UDP) communication. UDP is very fast, but operates with roughly 30% data loss. It is best practice to use UDP sockets when several packets are sent in a short period, and each packet is not particularly important.
+
See the following code example, which opens a UDP socket on port 80:
+
request socket_open 80UDP
+
+
After the socket has been opened, any other function within the module can use the following commands to write/read data to/from the socket:
+
request socket_write 80 data
+ request socket_read 80
+
+
When a socket is no longer needed (or the module has concluded), the socket must be closed by the program. This can be done like so:
+
request socket_close 80
+
+
+
TCP/IP Sockets
+
XCS provides Transmission Control Protocol (TCP) sockets for high-reliability networked communication. Unlike UDP, TCP will detect if a packet does not go through correctly and will resend the packet. So every TCP packet that is sent will be received by the client otherwise they are resent.
+
Although resending the packet ensures the information is delivered, it has a profound impact on efficiency and security. Flooding TCP sockets is a popular Dedicated Denial-of-Service (DDoS) strategy, so developers must detect/route attacks. Infrastructural mitigation is planned but not yet developed.
+
To open a socket for TCP on port 80:
+
request socket_open 80TCP
+
+
Once the socket is opened, data can be written/read exactly as it is in the UDP example. See below:
+
request socket_write 80 data
+ request socket_read 80
+
+
As with any other type of socket, make sure to close it at the end, so the network manager knows it is inactive.
\ No newline at end of file
diff --git a/docs/xcse/xcse.html b/docs/xcse/xcse.html
new file mode 100644
index 0000000..c989271
--- /dev/null
+++ b/docs/xcse/xcse.html
@@ -0,0 +1,64 @@
+XCS Environment · Codeus Tech
\ No newline at end of file
diff --git a/docs/xcse/xcse/index.html b/docs/xcse/xcse/index.html
new file mode 100644
index 0000000..c989271
--- /dev/null
+++ b/docs/xcse/xcse/index.html
@@ -0,0 +1,64 @@
+XCS Environment · Codeus Tech
\ No newline at end of file
diff --git a/docs/xcsl/regex.html b/docs/xcsl/regex.html
new file mode 100644
index 0000000..a015210
--- /dev/null
+++ b/docs/xcsl/regex.html
@@ -0,0 +1,14 @@
+xcsl/regex · Codeus Tech
XCS provides an interface for capturing regular expressions. The provided module uses regular-expressions.info as a guide, but does not follow its syntax/conventions in entirity.
\ No newline at end of file
diff --git a/docs/xcsl/regex/index.html b/docs/xcsl/regex/index.html
new file mode 100644
index 0000000..a015210
--- /dev/null
+++ b/docs/xcsl/regex/index.html
@@ -0,0 +1,14 @@
+xcsl/regex · Codeus Tech
XCS provides an interface for capturing regular expressions. The provided module uses regular-expressions.info as a guide, but does not follow its syntax/conventions in entirity.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-comments.html b/docs/xcsl/xcsl-comments.html
new file mode 100644
index 0000000..965c04a
--- /dev/null
+++ b/docs/xcsl/xcsl-comments.html
@@ -0,0 +1,93 @@
+Documentation · Codeus Tech
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-comments/index.html b/docs/xcsl/xcsl-comments/index.html
new file mode 100644
index 0000000..965c04a
--- /dev/null
+++ b/docs/xcsl/xcsl-comments/index.html
@@ -0,0 +1,93 @@
+Documentation · Codeus Tech
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-conditions.html b/docs/xcsl/xcsl-conditions.html
new file mode 100644
index 0000000..3f9e906
--- /dev/null
+++ b/docs/xcsl/xcsl-conditions.html
@@ -0,0 +1,100 @@
+Conditional Expressions · Codeus Tech
if ... then ... else ... statements are designed to efficiently route program flow/functionality, via boolean logic, to one of two paths. These are generally decided by logical and numeric comparisons.
+
Examine the following block of code:
+
if a <= b
+ thenTrue
+ elseFalse
+
+
If the value of 'a' is less than or equal to 'b', the entire clause will return True. Otherwise, the clause will return False.
+This can be used to control the behavior of a function under variable situations.
+
+
match with
+
match ... with ... statements are designed to efficiently route program flow/functionality to one of many paths. These are typically used for handling more complex cases than if ... then ... else ... statements.
+
Examine the following code:
+
match x with
+ True -> 1,
+ "Hello" -> 2,
+ Int y -> y,
+ _ -> 0(* Default Case *)
+
+
This match statement filters x into one of three integer values. Through the magic of arbitrary typing, x can be any type that provides a constructor for Booleans (True), Strings ("Hello"), and Integers (Int y). The result of a match case is constrained to a single type or typeclass; in this example, it resulted in an integer.
+
For a more practical example, see this function that sorts a color variable into the correct RGB (Red/Green/Blue) unit vector:
+
match color
+ with
+ Red -> RGB100,
+ Green -> RGB010,
+ Blue -> RGB001,
+ _ -> RGB000(* Default Case *)
+
+
+
is
+
... is ... statements are quickhand type/constructor equivalence checkers. If the left-hand-side variable matches the right-hand-side type/constructor, the entire statement returns True, otherwise it returns False.
+
For the next examples, assume 'b' is a constant of type color, and constructor Blue.
+The examples would both return 1.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-conditions/index.html b/docs/xcsl/xcsl-conditions/index.html
new file mode 100644
index 0000000..3f9e906
--- /dev/null
+++ b/docs/xcsl/xcsl-conditions/index.html
@@ -0,0 +1,100 @@
+Conditional Expressions · Codeus Tech
if ... then ... else ... statements are designed to efficiently route program flow/functionality, via boolean logic, to one of two paths. These are generally decided by logical and numeric comparisons.
+
Examine the following block of code:
+
if a <= b
+ thenTrue
+ elseFalse
+
+
If the value of 'a' is less than or equal to 'b', the entire clause will return True. Otherwise, the clause will return False.
+This can be used to control the behavior of a function under variable situations.
+
+
match with
+
match ... with ... statements are designed to efficiently route program flow/functionality to one of many paths. These are typically used for handling more complex cases than if ... then ... else ... statements.
+
Examine the following code:
+
match x with
+ True -> 1,
+ "Hello" -> 2,
+ Int y -> y,
+ _ -> 0(* Default Case *)
+
+
This match statement filters x into one of three integer values. Through the magic of arbitrary typing, x can be any type that provides a constructor for Booleans (True), Strings ("Hello"), and Integers (Int y). The result of a match case is constrained to a single type or typeclass; in this example, it resulted in an integer.
+
For a more practical example, see this function that sorts a color variable into the correct RGB (Red/Green/Blue) unit vector:
+
match color
+ with
+ Red -> RGB100,
+ Green -> RGB010,
+ Blue -> RGB001,
+ _ -> RGB000(* Default Case *)
+
+
+
is
+
... is ... statements are quickhand type/constructor equivalence checkers. If the left-hand-side variable matches the right-hand-side type/constructor, the entire statement returns True, otherwise it returns False.
+
For the next examples, assume 'b' is a constant of type color, and constructor Blue.
+The examples would both return 1.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-functions.html b/docs/xcsl/xcsl-functions.html
new file mode 100644
index 0000000..a844220
--- /dev/null
+++ b/docs/xcsl/xcsl-functions.html
@@ -0,0 +1,106 @@
+Functional Declarations · Codeus Tech
Users can write custom functions with the let keyword. See example below:
+
let three = 1 + 2
+
+
Any subsequent calls of the three function would result in the addition, and ultimately the integer value 3.
+
+
Function Parameters
+
more contextually-global
+Functions can have an arbitrary number of parameters (up to 255). Each parameter has a name, type, and associated real-time value. See the following example:
+
let sum x y = x + y
+
+
After this function declaration, sum can be called with two addable parameters.
+For example, If the following function was invoked, the result would be returned as 15:
+
sum 510
+
+
This instance used integers, but the sum function could easily handle floats, characters, and booleans as well.
+
+
Type Checking
+
Let's review the sum function again.
+
let sum x y = x + y
+
+
In this example, x and y can be any type that is implemented as a operand of addition. The sum function's return value can be of any type that is a valid result of addition.
+
+
Overloading Functions
+
Functions can always be overloaded, though there can only ever be a single unique function declaration for each parameter set. However, there can be any number of functions with a shared name, so long as the sets of their parameter types are all mutually exclusive.
+
See below for a practical example.
+
let calculate = 3;;
+let calculate x = x % 3;;
+let calculate x = x / 3.14
+
+
Let's review the three definitions of calculate.
+
+
In the first calculate definition, there is no parameter given and it always results in the same value.
+
In the second calculate definition, x is used in modulus, so it must be an integer.
+
In the third definition, x can be any real number type (e.g. float, double).
+
+
This is a totally valid way to define multiple functionalities for a single function identifier, without signficantly losing runtime efficiency.
+
+
Local Functions
+
Local functions are one-scope-use function declarations. In other words, these declarations are able to be used once, and then the identifier reverts to its previous meaning. In common lingo, this means local functions temporarily override global function declarations.
+
This concept is easiest explained through example. See the declarations below:
+
let funct = 1;;
+
+ let funct = 2in
+ funct
+
+
So what's the difference between these two expressions? Let's explore what happens during each of these. The first expression declares a function with no parameters named funct, equal to 1. The second expression declares a local function named funct that is temporarily equal to 2, then invokes the local function.
+
In all subsequent code in the module, funct would equal 1.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-functions/index.html b/docs/xcsl/xcsl-functions/index.html
new file mode 100644
index 0000000..a844220
--- /dev/null
+++ b/docs/xcsl/xcsl-functions/index.html
@@ -0,0 +1,106 @@
+Functional Declarations · Codeus Tech
Users can write custom functions with the let keyword. See example below:
+
let three = 1 + 2
+
+
Any subsequent calls of the three function would result in the addition, and ultimately the integer value 3.
+
+
Function Parameters
+
more contextually-global
+Functions can have an arbitrary number of parameters (up to 255). Each parameter has a name, type, and associated real-time value. See the following example:
+
let sum x y = x + y
+
+
After this function declaration, sum can be called with two addable parameters.
+For example, If the following function was invoked, the result would be returned as 15:
+
sum 510
+
+
This instance used integers, but the sum function could easily handle floats, characters, and booleans as well.
+
+
Type Checking
+
Let's review the sum function again.
+
let sum x y = x + y
+
+
In this example, x and y can be any type that is implemented as a operand of addition. The sum function's return value can be of any type that is a valid result of addition.
+
+
Overloading Functions
+
Functions can always be overloaded, though there can only ever be a single unique function declaration for each parameter set. However, there can be any number of functions with a shared name, so long as the sets of their parameter types are all mutually exclusive.
+
See below for a practical example.
+
let calculate = 3;;
+let calculate x = x % 3;;
+let calculate x = x / 3.14
+
+
Let's review the three definitions of calculate.
+
+
In the first calculate definition, there is no parameter given and it always results in the same value.
+
In the second calculate definition, x is used in modulus, so it must be an integer.
+
In the third definition, x can be any real number type (e.g. float, double).
+
+
This is a totally valid way to define multiple functionalities for a single function identifier, without signficantly losing runtime efficiency.
+
+
Local Functions
+
Local functions are one-scope-use function declarations. In other words, these declarations are able to be used once, and then the identifier reverts to its previous meaning. In common lingo, this means local functions temporarily override global function declarations.
+
This concept is easiest explained through example. See the declarations below:
+
let funct = 1;;
+
+ let funct = 2in
+ funct
+
+
So what's the difference between these two expressions? Let's explore what happens during each of these. The first expression declares a function with no parameters named funct, equal to 1. The second expression declares a local function named funct that is temporarily equal to 2, then invokes the local function.
+
In all subsequent code in the module, funct would equal 1.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-ops.html b/docs/xcsl/xcsl-ops.html
new file mode 100644
index 0000000..7e5d01e
--- /dev/null
+++ b/docs/xcsl/xcsl-ops.html
@@ -0,0 +1,138 @@
+Arithemic/Logical Operations · Codeus Tech
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-ops/index.html b/docs/xcsl/xcsl-ops/index.html
new file mode 100644
index 0000000..7e5d01e
--- /dev/null
+++ b/docs/xcsl/xcsl-ops/index.html
@@ -0,0 +1,138 @@
+Arithemic/Logical Operations · Codeus Tech
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-primitives.html b/docs/xcsl/xcsl-primitives.html
new file mode 100644
index 0000000..ca9e394
--- /dev/null
+++ b/docs/xcsl/xcsl-primitives.html
@@ -0,0 +1,126 @@
+Literal Values · Codeus Tech
Integers are the backbone of XCS and are typically the most efficient data type. They can be trivially defined as such:
+
10
+
+
This would form the number 10 of type int, a flexible datatype that represents the most contextually-efficient integer size.
+
To elaborate, integers can be signed or unsigned, as well as sized (in bits). Signed integers can be positive or negative; unsigned integers can only be positive but range twice as high in value. It is considered best practice to use the smallest suitable integer size, because it will be the fastest in execution.
+
XCS offers Unsigned Integer values with the following ranges:
XCSL offers two variations of Real Number values (e.g. numbers with decimal points):
+
+
Single-Precision Floating Point (float): 7-8 digit precision
+
Double-Precision Floating Point (double): 15-16 digit precision
+
+
+
Boolean Values
+
XCSL offers logical functionality in the form of Boolean values (True, False).
+
Constants and other named variables can typed as bool values, e.g.:
+
constant isConstant ofbool = True
+
+
+
Characters and Strings
+
XCSL provides two operators for defining ASCII literals:
+
+
Single-Quotation Marks are used to define characters: 'A'
+
Double-Quotation Marks are used to define strings: "Hello User!"
+
+
Escaped Characters
+
Special (Escaped) Characters can be defined using the backslash ('') character.
+
See the following list of escaped characters:
+
+
New-Line: '\n'
+
Tab Character: '\t'
+
+
+
Containers
+
Linked Lists
+
Linked Lists are the standard containers for collections of like-type data on XCS. They provide quick and easy ways to define and reference lists of numbers, letters, phrases, etc.
+
See below as an example, a constructed list of integers:
+
1 : [2, 3, 4, 5]
+
+
This example list would include 5 elements, starting with 1 and ending with 5.
+
+
Arrays
+
Arrays are similar to Linked Lists, except array entries are concatenated in memory (linked list entries are scattered in memory and dynamically linked).
+
+
Tuples
+
Tuples are containers for collections of mixed-type data on XCS. Unlike other containers, each tuple element's type expression can be independent of other elements' types.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-primitives/index.html b/docs/xcsl/xcsl-primitives/index.html
new file mode 100644
index 0000000..ca9e394
--- /dev/null
+++ b/docs/xcsl/xcsl-primitives/index.html
@@ -0,0 +1,126 @@
+Literal Values · Codeus Tech
Integers are the backbone of XCS and are typically the most efficient data type. They can be trivially defined as such:
+
10
+
+
This would form the number 10 of type int, a flexible datatype that represents the most contextually-efficient integer size.
+
To elaborate, integers can be signed or unsigned, as well as sized (in bits). Signed integers can be positive or negative; unsigned integers can only be positive but range twice as high in value. It is considered best practice to use the smallest suitable integer size, because it will be the fastest in execution.
+
XCS offers Unsigned Integer values with the following ranges:
XCSL offers two variations of Real Number values (e.g. numbers with decimal points):
+
+
Single-Precision Floating Point (float): 7-8 digit precision
+
Double-Precision Floating Point (double): 15-16 digit precision
+
+
+
Boolean Values
+
XCSL offers logical functionality in the form of Boolean values (True, False).
+
Constants and other named variables can typed as bool values, e.g.:
+
constant isConstant ofbool = True
+
+
+
Characters and Strings
+
XCSL provides two operators for defining ASCII literals:
+
+
Single-Quotation Marks are used to define characters: 'A'
+
Double-Quotation Marks are used to define strings: "Hello User!"
+
+
Escaped Characters
+
Special (Escaped) Characters can be defined using the backslash ('') character.
+
See the following list of escaped characters:
+
+
New-Line: '\n'
+
Tab Character: '\t'
+
+
+
Containers
+
Linked Lists
+
Linked Lists are the standard containers for collections of like-type data on XCS. They provide quick and easy ways to define and reference lists of numbers, letters, phrases, etc.
+
See below as an example, a constructed list of integers:
+
1 : [2, 3, 4, 5]
+
+
This example list would include 5 elements, starting with 1 and ending with 5.
+
+
Arrays
+
Arrays are similar to Linked Lists, except array entries are concatenated in memory (linked list entries are scattered in memory and dynamically linked).
+
+
Tuples
+
Tuples are containers for collections of mixed-type data on XCS. Unlike other containers, each tuple element's type expression can be independent of other elements' types.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-tethers.html b/docs/xcsl/xcsl-tethers.html
new file mode 100644
index 0000000..579f9cc
--- /dev/null
+++ b/docs/xcsl/xcsl-tethers.html
@@ -0,0 +1,106 @@
+Tether Operations · Codeus Tech
Process Tethers are conceptual bonds that allow two concurrently active source modules to communicate. For two (or more) modules to form a tether, they must abide by the following rules:
+
+
1.) Tethers must be formed between source modules at instant of execution
+
2.) Source Modules can arbitrarily form tethers with Tether Modules
+
3.) Tether Modules cannot form tethers with non-system modules
+
+
+
Forming Tethers
+
The best practice for forming tethers between modules is to use a Wrapper Function. An example wrapper might look like:
+
tether Module1 Module2 Module3
+
+
This function will trigger Module1-3 to all run simultaneously on separate threads. It will also inform the process scheduler that these three modules should be ran as a tethered Swarm.
+
+
1.) Modules can communicate with any other member of a mutual swarm.
+
2.) Modules can be in any number of swarms, concurrently.
+
3.) Modules can allow multiple active instances or restrict to a single concurrent instance.
+
+
+
The final return value for each module can then be accessed with the tuple operator.
+
For demonstration purposes, assume Module1, Module2, and Module3 all return integer values.
+
let wrapper = tether Module1Module2Module3
+ in
+ wrapper.{0} + wrapper.{1} + wrapper.{2}
+
+
In a practical example, each of these integer values might represent their corresponding module's status.
+
If you assume that 0 represents a successful run for each Module, the wrapper function's sum would:
+
+
Evaluate after each individual module concluded
+
Evaluate to 0 if all modules concluded successfully
+
+
+
Sending Messages
+
To send a message to a different module within a swarm, use the following XCSL functionality:
+
send KEY DATA
+
+
Data can be arbitrarily typed; it will be type-checked when the message enters the process scheduler.
+
See the following example:
+
send t3xtMe55Ag3 "Hello, Friend!"
+
+
+
Receiving Messages
+
XCSL implements a complimentary keyword (receive) for catching data from another module's send function. For example, a second module would be able to receive the string sent in the previous message.
+
print (receive t3xtMe55Ag3)
+
+
The receive keyword can determine the data type of a send through use-case context. The XCSL function above would result in the following standard output.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-tethers/index.html b/docs/xcsl/xcsl-tethers/index.html
new file mode 100644
index 0000000..579f9cc
--- /dev/null
+++ b/docs/xcsl/xcsl-tethers/index.html
@@ -0,0 +1,106 @@
+Tether Operations · Codeus Tech
Process Tethers are conceptual bonds that allow two concurrently active source modules to communicate. For two (or more) modules to form a tether, they must abide by the following rules:
+
+
1.) Tethers must be formed between source modules at instant of execution
+
2.) Source Modules can arbitrarily form tethers with Tether Modules
+
3.) Tether Modules cannot form tethers with non-system modules
+
+
+
Forming Tethers
+
The best practice for forming tethers between modules is to use a Wrapper Function. An example wrapper might look like:
+
tether Module1 Module2 Module3
+
+
This function will trigger Module1-3 to all run simultaneously on separate threads. It will also inform the process scheduler that these three modules should be ran as a tethered Swarm.
+
+
1.) Modules can communicate with any other member of a mutual swarm.
+
2.) Modules can be in any number of swarms, concurrently.
+
3.) Modules can allow multiple active instances or restrict to a single concurrent instance.
+
+
+
The final return value for each module can then be accessed with the tuple operator.
+
For demonstration purposes, assume Module1, Module2, and Module3 all return integer values.
+
let wrapper = tether Module1Module2Module3
+ in
+ wrapper.{0} + wrapper.{1} + wrapper.{2}
+
+
In a practical example, each of these integer values might represent their corresponding module's status.
+
If you assume that 0 represents a successful run for each Module, the wrapper function's sum would:
+
+
Evaluate after each individual module concluded
+
Evaluate to 0 if all modules concluded successfully
+
+
+
Sending Messages
+
To send a message to a different module within a swarm, use the following XCSL functionality:
+
send KEY DATA
+
+
Data can be arbitrarily typed; it will be type-checked when the message enters the process scheduler.
+
See the following example:
+
send t3xtMe55Ag3 "Hello, Friend!"
+
+
+
Receiving Messages
+
XCSL implements a complimentary keyword (receive) for catching data from another module's send function. For example, a second module would be able to receive the string sent in the previous message.
+
print (receive t3xtMe55Ag3)
+
+
The receive keyword can determine the data type of a send through use-case context. The XCSL function above would result in the following standard output.
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-types.html b/docs/xcsl/xcsl-types.html
new file mode 100644
index 0000000..cdf8960
--- /dev/null
+++ b/docs/xcsl/xcsl-types.html
@@ -0,0 +1,91 @@
+Type Declarations · Codeus Tech
XCSL tries to emphasize modularity throughout system design, whenever possible. This principle is largely upheld by the internal data type system, especially the concept of Arbitrary Types.
+
Arbitrary types allow functions to be efficiently built for most generalized case. For example:
+
let sum x y = x + y
+
+
While many languages require parameters to be explicitly typed, XCSL recognizes that x and y can be any type that implements addition. This leads to a single modular sum function that can interchangeably add integers, real numbers, characters, and booleans.
+
+
Type Aliases
+
It is frequently helpful to duplicate an existing type with an additional name, aka Alias. This allows code to be naturally self-documenting. Self-documenting code is a principle where internal functionality is made obvious via nomenclature. See a common example below:
+
type address = int
+
+
Memory addresses are integer values, where the integer itself does not matter, but rather the value in memory it points to. When working with addresses, it is better practice to label values as addresses rather than integers to distiquish memory pointers from data.
+
+
Type Constructors
+
Type Constructors are used to define different instances of the same type of data.
+
See the following color example:
+
type color = Red | Green | Blue | RGBof (int; int; int)
+
+
Red, Green, and Blue are all valid constructors of the color type. Additionally, there is a constructor (RGB) that accepts three integer parameters. This set of constructors allows developers to quickly use common colors, as well as form new colors by mixing red, green, and blue.
+
+
Complex Types
+
The aforementioned type constructors built simple type instances (e.g. no records). However, users are able to define Complex Types with records. See the following example using a person type.
+
type person =
+ name : string,
+ age : int,
+ height : int
+
+
Then, it can be called to create specific people.
+
constant jim of person =
+ name = "jim",
+ age = 21,
+ height = 67
+
\ No newline at end of file
diff --git a/docs/xcsl/xcsl-types/index.html b/docs/xcsl/xcsl-types/index.html
new file mode 100644
index 0000000..cdf8960
--- /dev/null
+++ b/docs/xcsl/xcsl-types/index.html
@@ -0,0 +1,91 @@
+Type Declarations · Codeus Tech
XCSL tries to emphasize modularity throughout system design, whenever possible. This principle is largely upheld by the internal data type system, especially the concept of Arbitrary Types.
+
Arbitrary types allow functions to be efficiently built for most generalized case. For example:
+
let sum x y = x + y
+
+
While many languages require parameters to be explicitly typed, XCSL recognizes that x and y can be any type that implements addition. This leads to a single modular sum function that can interchangeably add integers, real numbers, characters, and booleans.
+
+
Type Aliases
+
It is frequently helpful to duplicate an existing type with an additional name, aka Alias. This allows code to be naturally self-documenting. Self-documenting code is a principle where internal functionality is made obvious via nomenclature. See a common example below:
+
type address = int
+
+
Memory addresses are integer values, where the integer itself does not matter, but rather the value in memory it points to. When working with addresses, it is better practice to label values as addresses rather than integers to distiquish memory pointers from data.
+
+
Type Constructors
+
Type Constructors are used to define different instances of the same type of data.
+
See the following color example:
+
type color = Red | Green | Blue | RGBof (int; int; int)
+
+
Red, Green, and Blue are all valid constructors of the color type. Additionally, there is a constructor (RGB) that accepts three integer parameters. This set of constructors allows developers to quickly use common colors, as well as form new colors by mixing red, green, and blue.
+
+
Complex Types
+
The aforementioned type constructors built simple type instances (e.g. no records). However, users are able to define Complex Types with records. See the following example using a person type.
+
type person =
+ name : string,
+ age : int,
+ height : int
+
+
Then, it can be called to create specific people.
+
constant jim of person =
+ name = "jim",
+ age = 21,
+ height = 67
+
\ No newline at end of file
diff --git a/docs/xcsl/xcsl.html b/docs/xcsl/xcsl.html
new file mode 100644
index 0000000..04e6d1d
--- /dev/null
+++ b/docs/xcsl/xcsl.html
@@ -0,0 +1,69 @@
+XCS Language · Codeus Tech
Here, you can find information useful for development of X-Ita Control System Language (XCSL) -- specifically targeting 64-bit ARM architecture. For documentation and usage information, please see below:
\ No newline at end of file
diff --git a/docs/xcsl/xcsl/index.html b/docs/xcsl/xcsl/index.html
new file mode 100644
index 0000000..04e6d1d
--- /dev/null
+++ b/docs/xcsl/xcsl/index.html
@@ -0,0 +1,69 @@
+XCS Language · Codeus Tech
Here, you can find information useful for development of X-Ita Control System Language (XCSL) -- specifically targeting 64-bit ARM architecture. For documentation and usage information, please see below:
\ No newline at end of file
diff --git a/en/about.html b/en/about.html
new file mode 100644
index 0000000..ee3b1f2
--- /dev/null
+++ b/en/about.html
@@ -0,0 +1,11 @@
+Codeus Tech
cfagley@codeus.tech Cody is a multilinguist programmer who has been coding/hacking from a young age. He grew up in a collection of small towns in Wyoming (e.g. Basin, Powell, and Sheridan). Cody holds a degree in Computer Science from University of Wyoming; since graduating he has focused his energy on building Codeus Tech and X-Ita Control System. He built Codeus Tech to extend his research in intrinsically-secure systems design.
+
Lisa Fagley
+
lisa.ann.fagley@gmail.com Lisa is also a Wyoming native and alumni of University of Wyoming (Finance). She has been a key asset in fine tuning Codeus Tech's financial plan. As primary financier of Codeus Tech, Lisa also helps Wells Fargo clientele make better long-term financial decisions.
+
Advisors
David Bohling
+
dbohlin1@uwyo.edu David Bohling (Dave) previously served as Principle Investigator on semiconductor research, funded by DARPA. His investigation was ultimately completed under-budget and faster than expected. Dave has a proven track record of successfully managing various technologies in concurrency.
+
Ed Hart
+
Codeus Tech is honored to be advised by Edward Hart, previous Deputy Director for Information Security of National Security Agency (NSA). While working with NSA, Ed oversaw development of some of the world's most advanced and secure IoT devices. In private industry, he has played a key role in several successful entities -- founding, managing and as a member of various boards.
+
Jerad Stack
+
Jerad Stack is a successful Founder/CEO and Wyoming business leader. Jerad has had a prolific career in engineering and simulation with Firehole Composites (later acquired by AutoDesk). He continues to use his expertise to help growing companies reach their next steps.
+
\ No newline at end of file
diff --git a/en/about/index.html b/en/about/index.html
new file mode 100644
index 0000000..ee3b1f2
--- /dev/null
+++ b/en/about/index.html
@@ -0,0 +1,11 @@
+Codeus Tech
cfagley@codeus.tech Cody is a multilinguist programmer who has been coding/hacking from a young age. He grew up in a collection of small towns in Wyoming (e.g. Basin, Powell, and Sheridan). Cody holds a degree in Computer Science from University of Wyoming; since graduating he has focused his energy on building Codeus Tech and X-Ita Control System. He built Codeus Tech to extend his research in intrinsically-secure systems design.
+
Lisa Fagley
+
lisa.ann.fagley@gmail.com Lisa is also a Wyoming native and alumni of University of Wyoming (Finance). She has been a key asset in fine tuning Codeus Tech's financial plan. As primary financier of Codeus Tech, Lisa also helps Wells Fargo clientele make better long-term financial decisions.
+
Advisors
David Bohling
+
dbohlin1@uwyo.edu David Bohling (Dave) previously served as Principle Investigator on semiconductor research, funded by DARPA. His investigation was ultimately completed under-budget and faster than expected. Dave has a proven track record of successfully managing various technologies in concurrency.
+
Ed Hart
+
Codeus Tech is honored to be advised by Edward Hart, previous Deputy Director for Information Security of National Security Agency (NSA). While working with NSA, Ed oversaw development of some of the world's most advanced and secure IoT devices. In private industry, he has played a key role in several successful entities -- founding, managing and as a member of various boards.
+
Jerad Stack
+
Jerad Stack is a successful Founder/CEO and Wyoming business leader. Jerad has had a prolific career in engineering and simulation with Firehole Composites (later acquired by AutoDesk). He continues to use his expertise to help growing companies reach their next steps.
+
\ No newline at end of file
diff --git a/en/index.html b/en/index.html
new file mode 100644
index 0000000..d58d3dd
--- /dev/null
+++ b/en/index.html
@@ -0,0 +1,17 @@
+Codeus Tech